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

Ao tentar entender como uma instrução SQL está sendo executada, às vezes é recomendado consultar o plano de explicação. Qual é o processo pelo qual se deve passar para interpretar (dar sentido) a 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."

Estremeço sempre que vejo comentários de que as varreduras de tabelas completas são ruins e o acesso ao índice é bom. Varreduras completas de tabela, varreduras de intervalo de índice, varreduras de índice completo rápidas, loops aninhados, junção de mesclagem, junções de hash etc. são simplesmente mecanismos de acesso que devem ser entendidos pelo analista e combinados com um conhecimento da estrutura do banco de dados e o propósito de uma consulta em a fim de 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 alcançar os objetivos da consulta. Falando como um data warehouse e cara de BI, meu sinalizador de aviso número um para desempenho é um método de acesso baseado em índice e um loop aninhado.

Portanto, para o mecanismo de como ler um plano de explicação, 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.

Também tenha um google para "feedback de cardinalidade", uma técnica em que 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, acredito.

Portanto, o ponto principal: entenda os mecanismos de acesso. Entenda o banco de dados. Entenda a intenção da consulta. Evite regras gerais.

Este assunto é muito grande para responder em uma pergunta como esta. Você deve reservar um tempo para ler o Guia de ajuste de desempenho da Oracle

Os dois exemplos abaixo mostram uma varredura FULL e uma varredura FAST usando um INDEX.

É melhor se concentrar em seu custo e 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 E / S, e a cardinalidade é o número de linhas que o Oracle espera analisar. Reduzir ambos é uma coisa boa.

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

Exemplo 1:

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

Exemplo 2 usando índices:

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

E como já sugerido, atente para TABLE SCAN. Geralmente, você pode evitá-los.

Procurar coisas como varreduras sequenciais pode ser algo útil, mas a realidade está nos números ... exceto quando os números são apenas estimativas! O que geralmente é muito mais útil do que olhar para um plano de consulta é olhar para a execução real . 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 realmente está acontecendo, em vez do que o planejador pensa vai acontecer. Muitas vezes, você descobrirá que uma varredura 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 as diferentes partes do plano. Nesse caso, apenas procure degraus que tenham setas finas entrando e uma seta grossa saindo. Se não estiver usando uma GUI, você precisará observar os números e procurar onde de repente eles ficam muito maiores. Com um pouco de prática, torna-se bastante fácil identificar as áreas problemáticas.

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 Oracle online, onde muitos desses tipos de regras são explicados.

Uma coisa a ter em mente é que os planos de explicação são, na verdade, melhores suposições.

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

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

A saída da explicação informa quanto tempo cada etapa demorou. A primeira coisa é encontrar os passos 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.

Um "Ah, não, isso não está certo" costuma vir na forma de uma varredura de mesa . As varreduras de tabela não utilizam nenhum índice especial e podem contribuir para a eliminação de todos os caches de memória úteis. No postgreSQL, por exemplo, você verá que se parece com isso.

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

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

Basicamente, você analisa cada operação e vê se as operações "fazem sentido", dado o seu conhecimento de como devem funcionar.

Por exemplo, se você estiver unindo duas tabelas, A e B em suas respectivas colunas C e D (AC = BD), e seu plano mostra uma varredura de índice agrupado (termo do SQL Server - não tenho certeza do termo oracle) na tabela A, em seguida, uma junção de loop aninhado 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 um par de varreduras de índice (sobre os índices nas colunas unidas) seguido por uma junção de mesclagem. Uma investigação mais aprofundada pode revelar estatísticas ruins que fazem o otimizador escolher esse padrão de junção ou um índice que não existe de fato.

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

Eu procuro principalmente por varreduras de índice ou de tabela. Isso geralmente me diz 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_analysis_p1.aspx :

Se você vir qualquer um dos itens a seguir em um plano de execução, deverá considerá-los sinais de aviso e investigá-los para possíveis problemas de desempenho. Cada um deles é menos do que 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ê puder evitá-los, mais rápido será o desempenho da consulta.

Regras de ouro

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

• Oracle Docs
• ASKTOM
• Documentos do SQL Server
  )

Ruim

Varreduras de tabela de várias tabelas grandes

Boa

Usando um índice único, 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 lotes (4 ou mais) de tabelas em 2 consultas menores e uma tabela temporária.