Ao criar tabelas de várias junções para uso em análise, quando é preferível usar visualizações em vez de criar uma nova tabela?
Uma razão pela qual eu preferiria usar visualizações é que o esquema do banco de dados foi desenvolvido por nosso administrador de dentro do Ruby, e eu não estou familiarizado com o Ruby. Posso solicitar a criação de tabelas, mas requer uma etapa adicional e gostaria de mais flexibilidade ao desenvolver/testar novas junções.
Comecei a usar visualizações seguindo a resposta a uma pergunta relacionada no SO ( Quando usar R, quando usar SQL ). A resposta mais votada começa "faça as manipulações de dados em SQL até que os dados estejam em uma única tabela e, em seguida, faça o resto em R".
Comecei a usar visualizações, mas encontrei alguns problemas com visualizações:
- as consultas são muito mais lentas
- As visualizações não são despejadas da produção para o banco de dados de backup que uso para análise.
As visualizações são apropriadas para esse uso? Em caso afirmativo, devo esperar uma penalidade de desempenho? Existe uma maneira de acelerar as consultas nas visualizações?
As visualizações no MySQL são tratadas usando um de dois algoritmos diferentes:
MERGE
ouTEMPTABLE
.MERGE
é simplesmente uma expansão de consulta com aliases apropriados.TEMPTABLE
é exatamente o que parece, a exibição coloca os resultados em uma tabela temporária antes de executar a cláusula WHERE e não há índices nela.A 'terceira' opção é
UNDEFINED
, que diz ao MySQL para selecionar o algoritmo apropriado. O MySQL tentará usarMERGE
porque é mais eficiente. Advertência principal:Eu me arriscaria a adivinhar que suas VIEWS estão exigindo o algoritmo TEMPTABLE, causando problemas de desempenho.
Aqui está uma postagem de blog muito antiga sobre o desempenho das visualizações no MySQL e não parece ter melhorado.
No entanto, pode haver alguma luz no fim do túnel sobre essa questão de tabelas temporárias que não contêm índices (causando varreduras completas de tabela). Em 5.6 :
Como o @ypercube aponta, o MariaDB 5.3 adicionou a mesma otimização. Este artigo tem uma visão geral interessante do processo:
As visualizações são ferramentas de segurança. Você não deseja que um determinado usuário ou aplicativo saiba onde está sua tabela de dados, você fornece uma visualização apenas com as colunas necessárias.
Lembre-se de que visualizações sempre degradam o desempenho, consultas semelhantes devem ser procedimentos e funções armazenados, não visualizações.
Para fazer um ajuste de consulta, siga sempre as melhores práticas, evite usar funções em cláusulas WHERE, crie índices para acelerar seleções, mas não abuse dos índices degradam inserções, atualizações e exclusões.
Existe uma boa documentação que pode ajudá-lo: http://www.toadworld.com/LinkClick.aspx?fileticket=3qbwCnzY/0A=&tabid=234
eu acho que as visualizações são a estrutura predefinida (sem dados) para mesclar tabelas em uma para superar a consulta de várias tabelas, que pode ser usada a partir de dados reais para consultas relacionais rápidas ...