Como você interpreta o plano de explicação de uma consulta?

Question

Ao tentar entender como uma instrução SQL está sendo executada, às vezes é recomendável consultar o plano de explicação.Qual é o processo pelo qual se deve passar na interpretação (fazer sentido) de um plano de explicação?O que deve se destacar como: "Oh, isso está funcionando esplendidamente?" versus "Oh não, isso não está certo".

Answer 1

Estremeço sempre que vejo comentários de que verificações completas de tabelas são ruins e que o acesso ao índice é bom.Varreduras completas de tabela, varreduras de intervalo de índice, varreduras rápidas de índice completo, loops aninhados, junção de mesclagem, junções de hash, etc.são simplesmente mecanismos de acesso que devem ser compreendidos pelo analista e combinados com o conhecimento da estrutura do banco de dados e do propósito de uma consulta para chegar a qualquer conclusão significativa.

Uma varredura completa é simplesmente a maneira mais eficiente de ler uma grande proporção dos blocos de um segmento de dados (uma tabela ou uma (sub)partição de tabela) e, embora muitas vezes possa indicar um problema de desempenho, isso ocorre apenas no contexto se é um mecanismo eficiente para atingir os objetivos da consulta.Falando como um cara de data warehouse e BI, meu sinalizador de alerta número um para desempenho é um método de acesso baseado em índice e um loop aninhado.

Portanto, para o mecanismo de leitura de um plano explicado, a documentação do Oracle é um bom guia: http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/ex_plan.htm#PFGRF009

Leia também o Guia de ajuste de desempenho.

Tenha também um google para "feedback de cardinalidade", uma técnica na qual um plano de explicação pode ser usado para comparar as estimativas de cardinalidade em vários estágios de uma consulta com as cardinalidades reais experimentadas durante a execução.Wolfgang Breitling é o autor do método, creio eu.

Então, resultado final:compreender os mecanismos de acesso.Entenda o banco de dados.Entenda a intenção da consulta.Evite regras práticas.

Answer 2

Este assunto é muito grande para ser respondido em uma pergunta como esta.Você deveria reservar algum tempo para ler Guia de ajuste de desempenho da Oracle

Answer 3

Os dois exemplos abaixo mostram uma varredura COMPLETA e uma varredura RÁPIDA usando um ÍNDICE.

É melhor se concentrar no custo e na cardinalidade.Observando os exemplos, o uso do índice reduz o custo de execução da consulta.

É um pouco mais complicado (e não tenho 100% de controle sobre isso), mas basicamente o custo é uma função do custo de CPU e IO, e a cardinalidade é o número de linhas que o Oracle espera analisar.Reduzir ambos é uma coisa boa.

Não se esqueça que o custo de uma consulta pode ser influenciado pela sua consulta e pelo modelo do otimizador Oracle (por exemplo:COST, CHOOSE etc) e com que frequência você executa suas estatísticas.

Exemplo 1:

VERIFICAR http://docs.google.com/a/shanghainetwork.org/File?id=dd8xj6nh_7fj3cr8dx_b

Exemplo 2 usando índices:

ÍNDICE http://docs.google.com/a/fukuoka-now.com/File?id=dd8xj6nh_9fhsqvxcp_b

E como já sugerido, fique atento ao TABLE SCAN.Geralmente você pode evitá-los.

Answer 4

Procurar coisas como varreduras sequenciais pode ser útil, mas a realidade está nos números...exceto quando os números são apenas estimativas!O que geralmente é distante mais útil do que olhar para uma consulta plano está olhando para o real execução.No Postgres, esta é a diferença entre EXPLAIN e EXPLAIN ANALYZE.EXPLAIN ANALYZE realmente executa a consulta e obtém informações de tempo real para cada nó.Isso permite que você veja o que está na verdade acontecendo, em vez do que o planejador acha acontecerá.Muitas vezes você descobrirá que uma verificação sequencial não é um problema; em vez disso, é outra coisa na consulta.

A outra chave é identificar qual é a etapa realmente cara.Muitas ferramentas gráficas usarão setas de tamanhos diferentes para indicar quanto custam diferentes partes do plano.Nesse caso, basta procurar etapas que tenham setas finas entrando e uma seta grossa saindo.Se você não estiver usando uma GUI, precisará observar os números e procurar onde eles repentinamente ficam muito maiores.Com um pouco de prática, torna-se bastante fácil identificar as áreas problemáticas.

Answer 5

Na verdade, para questões como essas, a melhor coisa a fazer é ASKTOM.Em particular, sua resposta a essa pergunta contém links para o documento on-line da Oracle, onde muitos desses tipos de regras são explicados.

Uma coisa a ter em mente é que os planos explicados são realmente os melhores palpites.

Seria uma boa ideia aprender a usar o sqlplus e experimentar o comando AUTOTRACE.Com alguns números concretos, geralmente você pode tomar decisões melhores.

Mas você deveria ASKTOM.Ele sabe tudo sobre isso :)

Answer 6

A saída da explicação informa quanto tempo cada etapa demorou.A primeira coisa é encontrar as etapas que demoraram muito e entender o que significam.Coisas como uma varredura sequencial indicam que você precisa de índices melhores - é principalmente uma questão de pesquisa em seu banco de dados e experiência específicos.

Answer 7

Um "Ah, não, isso não está certo" geralmente aparece na forma de um varredura de mesa.As varreduras de tabela não utilizam nenhum índice especial e podem contribuir para a limpeza de todos os caches de memória úteis.No postgreSQL, por exemplo, você verá que é assim.

Seq Scan on my_table  (cost=0.00..15558.92 rows=620092 width=78)

Às vezes, as varreduras de tabela são ideais, digamos, ao usar um índice para consultar as linhas.No entanto, este é um daqueles padrões de bandeira vermelha que você parece estar procurando.

Answer 8

Basicamente, você dá uma olhada em cada operação e vê se as operações "fazem sentido" dado o seu conhecimento de como elas deveriam funcionar.

Por exemplo, se você estiver unindo duas tabelas, A e B em suas respectivas colunas C e D (A.C = B.D), e seu plano mostrar uma varredura de índice clusterizado (termo do SQL Server - não tenho certeza do termo oracle) na tabela A, então um loop aninhado se junta a uma série de buscas de índice clusterizado na tabela B, você pode pensar que houve um problema.Nesse cenário, você pode esperar que o mecanismo faça duas varreduras de índice (nos índices nas colunas unidas) seguidas por uma junção de mesclagem.Uma investigação mais aprofundada pode revelar estatísticas ruins, fazendo com que o otimizador escolha aquele padrão de junção ou um índice que na verdade não existe.

Answer 9

observe a porcentagem de tempo gasto em cada subseção do plano e considere o que o mecanismo está fazendo.por exemplo, se estiver verificando uma tabela, considere colocar um índice no(s) campo(s) que está verificando

Answer 10

Procuro principalmente varreduras de índices ou tabelas.Isso geralmente indica que estou faltando um índice em uma coluna importante que está na instrução where ou na instrução join.

De http://www.sql-server-performance.com/tips/query_execution_plan_análise_p1.aspx:

Se você vir algum dos seguintes em um plano de execução, deverá considerá -los avisar sinais e investigá -los para possíveis problemas de desempenho.Cada um deles é menos do que o ideal de uma perspectiva de desempenho.

* Index or table scans: May indicate a need for better or  additional indexes.
* Bookmark Lookups: Consider changing the current clustered index,
  consider using a covering index, limit
  the number of columns in the SELECT
  statement.
* Filter: Remove any functions in the WHERE clause, don't include wiews
  in your Transact-SQL code, may need
  additional indexes.
* Sort: Does the data really need to be sorted? Can an index be used to
  avoid sorting? Can sorting be done at
  the client more efficiently? 

Nem sempre é possível evitá -los, mas quanto mais você pode evitá -los, o desempenho mais rápido da consulta será.

Answer 11

Regras de ouro

(você provavelmente também deseja ler os detalhes:

• Documentos Oracle
• ASKTOM
• Documentos do SQL Server
  )

Ruim

Varreduras de tabelas de várias tabelas grandes

Bom

Usando um índice exclusivo
O índice inclui todos os campos obrigatórios

Vitória mais comum

Em cerca de 90% dos problemas de desempenho que vi, a vitória mais fácil é dividir uma consulta com muitas (4 ou mais) tabelas em 2 consultas menores e uma tabela temporária.