Uma vista é mais rápida do que uma simples consulta?
é um
select * from myView
mais rápido do que a consulta em si para criar a vista (a fim de ter o mesmo conjunto de resultados):
select * from ([query to create same resultSet as myView])
?
não é totalmente claro para mim se a vista usa algum tipo de cache tornando-o mais rápido em comparação com uma consulta simples.
14 answers
Sim , as vistas podem ter um índice agrupado atribuído e, quando o fizerem, armazenarão resultados temporários que podem acelerar as consultas resultantes.
Pelo menos três pessoas rejeitaram esta. Com todo o respeito, eu acho que eles estão apenas errados; a própria documentação da Microsoft deixa muito claro que os pontos de vista podem melhorar o desempenho.Em primeiro lugar, as vistas simples são expandidas e, por isso, não contribuem directamente para melhorias de desempenho-que muito é verdade. No entanto, os pontos de vista indexados podemdramaticamente melhorar o desempenho.
Deixe-me ir directamente para a documentação:
Depois que um índice único agrupado é criado na vista, o conjunto de resultados da vista é materializado imediatamente e persistiu no armazenamento físico na base de dados, poupando a sobrecarga de executar esta operação dispendiosa no tempo de execução.
Em segundo lugar, estes pontos de vista indexados podem funcionar mesmo quando não são directamente referenciado por outra consulta como o Optimizador irá usá-los no lugar de uma referência de tabela, quando apropriado.
Novamente, a documentação:
A janela indexada pode ser usada em uma execução de consulta de duas maneiras. A consulta pode referenciar a visualização indexada diretamente, ou, mais importante, o otimizador da consulta pode selecionar a visualização se ele determinar que a visualização pode ser substituída por parte ou por toda a consulta no plano de consulta de menor custo. No segundo caso, a vista indexada é utilizado em vez das tabelas subjacentes e dos seus índices ordinários. A vista não precisa ser referenciada na consulta para o otimizador de consulta para usá-lo durante a execução da consulta. Isto permite que as aplicações existentes se beneficiem das vistas indexadas recentemente criadas sem alterar essas aplicações.
Esta documentação, bem como gráficos que demonstram melhorias de desempenho, podem ser encontrados aqui.
Atualização 2: {[3] } a resposta foi criticada na base que é o" índice "que fornece a vantagem de desempenho, não a "visão"."No entanto, isso é facilmente refutado.
Digamos que somos uma empresa de software num país pequeno; utilizarei a lituânia como exemplo. Vendemos software em todo o mundo e mantemos os nossos registos numa base de dados de servidores SQL. Nós somos muito bem sucedidos e assim, em alguns anos, temos 1.000.000 mais registros. No entanto, muitas vezes precisamos de relatar as vendas para fins fiscais e descobrimos que só vendemos 100 cópias do nosso software em nosso pai. Ao criar uma visão indexada apenas dos registros lituanos, podemos manter os registros que precisamos em um cache indexado como descrito na documentação do MS. Quando executarmos os nossos relatórios para as vendas lituanas em 2008, a nossa consulta irá procurar através de um índice com uma profundidade de apenas 7 (Log2(100) com algumas folhas não utilizadas). Se fizéssemos o mesmo sem a vista e dependêssemos apenas de um índice para a mesa, teríamos de atravessar uma árvore de índice com uma profundidade de busca de 21!Claramente, o A própria visão nos proporcionaria uma vantagem de desempenho (3x) sobre o Simples Uso do Índice sozinho. Eu tentei usar um exemplo do mundo real, mas você vai notar que uma simples lista de vendas lituanas nos daria uma vantagem ainda maior.
Note que só estou a usar uma árvore B direita, por exemplo. Embora eu esteja bastante certo que o servidor SQL usa alguma variante de uma árvore b, Eu não sei os detalhes. No entanto, a questão mantém-se.Actualização 3: {[3] } a questão surgiu sobre se uma vista indexada apenas usa um índice colocado na tabela subjacente. Isto é, parafraseando: "uma visão indexada é apenas o equivalente a um índice padrão e não oferece nada de novo ou único a uma visão."Se isso fosse verdade, é claro, então a análise acima seria incorreta! Deixe-me fornecer uma citação da documentação da Microsoft que demonstra por que eu acho que esta crítica não é válida ou verdadeira:
Usar índices para melhorar o desempenho da consulta não é um novo conceito; no entanto, os pontos de vista indexados proporcionam benefícios adicionais de desempenho que não podem ser alcançados utilizando índices normalizados.
Em conjunto com a citação acima relativa à persistência de dados no armazenamento físico e outras informações na documentação sobre como os índices são criados nas vistas, penso que é seguro dizer que uma vista indexada é não apenas uma opção em cache SQL que acontece usar um índice definido na tabela principal. Assim, continuo a manter esta resposta.
De um modo geral, não. as vistas são usadas principalmente para conveniência e segurança, não para melhorias de velocidade.
Dito isto, o SQL Server 2000 e acima tem uma funcionalidade especial chamada Pontos de vista indexados que Pode melhorar muito o desempenho, mas você tem que criar pontos de vista indexados de acordo com um conjunto muito de orientações específicas.
Existe uma referência importante nos livros em linha no que diz respeito à resolução ver resolução .
Aqui. é um artigo que descreve os benefícios e a criação de pontos de vista indexados:Por muitos anos, o Microsoft® SQL Server™ tem suportado a capacidade de criar tabelas virtuais conhecidas como vistas. Historicamente, estes pontos de vista serviram principais objectivos:
Fornecer um mecanismo de segurança que restringe os utilizadores a um certo subconjunto de dados em uma ou mais tabelas de base.
Fornecer um mecanismo que permita programadores para personalizar como os utilizadores podem ver logicamente os dados armazenados na base tabela.
Com o SQL Server 2000, o a funcionalidade das vistas do servidor SQL foi expandido para fornecer o desempenho do sistema beneficio. É possível criar um unique clustered index on a view, as bem como os índices não-resumidos, para melhorar o desempenho do acesso aos dados perguntas muito complexas. No servidor SQL 2000 e 2005, um ponto de vista é referido um índice único agrupado como vista indexada.
No servidor SQL, pelo menos, os planos de pesquisa são armazenados na 'cache' do plano tanto para as visualizações como para as consultas SQL normais, com base nos parâmetros da consulta/visualização. Para ambos, eles são descartados do cache quando eles foram não utilizados por um período suficiente e o espaço é necessário para alguma outra consulta recém-submetida. Depois disso, se a mesma consulta é emitida, ela é recompilada e o plano é colocado de volta no cache. Então não, não há diferença, dado que você está reutilizando a mesma consulta SQL e a mesma ver com a mesma frequência.
Obviamente, em geral, uma visão, por sua própria natureza (que alguém pensou que era para ser usado com freqüência suficiente para torná-lo em uma visão) é geralmente mais provável de ser "reutilizada" do que qualquer afirmação SQL arbitrária.EDIT:eu estava errado, e você deve ver As Marcas respondem acima.
Não posso falar por experiência com o servidor SQL , mas para a maioria das bases de dados a resposta seria não. O único benefício potencial que você obtém, em termos de desempenho, de usar uma visão é que ela pode potencialmente criar alguns caminhos de acesso com base na consulta. Mas a principal razão para usar uma visão é simplificar uma consulta ou padronizar uma maneira de acessar alguns dados em uma tabela. De um modo geral, não vai ter um evento beneficente. Mas posso estar enganado.
Eu arranjaria um exemplo mais complicado e teria tempo para ver.O meu entendimento é que há algum tempo atrás, uma vista seria mais rápida porque o servidor SQL poderia armazenar um plano de execução e depois usá-lo em vez de tentar descobrir um no momento. Eu acho que os ganhos de desempenho hoje em dia provavelmente não é tão grande como era antes, mas eu teria que adivinhar que haveria alguma melhoria marginal para usar a vista.
Definitivamente uma vista é melhor do que uma consulta aninhada para o servidor SQL. Sem saber exatamente por que é melhor (até que eu li O post de Mark Brittingham), eu tinha executado alguns testes e experimentado melhorias de desempenho quase chocantes ao usar uma visão versus uma consulta aninhada. Depois de executar cada versão da consulta várias centenas de vezes em uma linha, a versão de visualização da consulta terminou em metade do tempo. Eu diria que isso é prova suficiente para mim.
Não há nenhuma diferença prática e se você ler BOL você vai descobrir que sempre que o seu SQL SQL simples selecione * de X faz tirar vantagem de cache plano, etc.
Deve haver algum ganho trivial em ter o plano de execução armazenado, mas será insignificante.
O objectivo de uma vista é usar a consulta vezes sem conta. Para esse fim, servidor SQL, Oracle, etc. irá tipicamente fornecer uma versão" cache" ou "compilada" da sua visão, melhorando assim o seu desempenho. Em geral, isso deve executar melhor do que uma consulta" simples", embora se a consulta é realmente muito simples, os benefícios podem ser negligenciáveis.
Agora, se você está fazendo uma consulta complexa, crie a vista.Na minha descoberta, usar a vista é um pouco mais rápido do que uma consulta normal. Meu procedimento armazenado levava cerca de 25 minutos (o tempo de trabalho com um diferente maiores conjuntos de registros e várias associações) e depois usando o modo de exibição (não agrupados), o desempenho foi um pouco mais rápido, mas não significativo. Eu tive que usar algumas outras técnicas de otimização de consulta/método para torná-lo uma mudança dramática.
Uma vista em qualquer tipo de loop causará uma desaceleração grave porque a vista é repovoada cada vez que é chamada no loop. O mesmo que uma consulta. Nesta situação, uma tabela temporária usando # ou @ para manter seus dados em loop através é mais rápido do que uma vista ou uma consulta.
Então tudo depende do situacao.Seleccione de uma vista ou de uma tabela não fará muito sentido.
Claro que se a vista não tiver ligações desnecessárias, campos, etc. Você pode verificar o plano de execução de suas consultas, junções e índices utilizados para melhorar o desempenho da vista.
Você pode até criar um índice de visualizações para requisitos de pesquisa mais rápidos. http://technet.microsoft.com/en-us/library/cc917715.aspx
Mas se estiver a procurar como '%...% 'do que o motor sql não beneficiará de um índice na coluna de texto. Se você pode forçar seus usuários a fazer pesquisas como '...% 'do que isso será rápido
Referenciada a resposta em fóruns asp : https://forums.asp.net/t/1697933.aspx?Which+is+faster+when+using+SELECT+query+VIEW+or+Table+