it-swarm-pt.tech

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

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

87
user290

Tremo sempre que vejo comentários de que as tabelas completas são ruins e o acesso ao índice é bom. Varreduras de tabela completa, varreduras de intervalo de índice, varreduras completas rápidas de índice, 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 o conhecimento da estrutura do banco de dados e o objetivo de uma consulta no 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 data warehouse e um 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.

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, acredito.

Então, em suma: entenda os mecanismos de acesso. Entenda o banco de dados. Entenda a intenção da consulta. Evite regras práticas.

78
David Aldridge

Esse assunto é grande demais para ser respondido em uma pergunta como esta. Você deve levar algum tempo para ler Guia de ajuste de desempenho da Oracle

13
Tony Andrews

Os dois exemplos abaixo mostram uma verificação COMPLETA e uma verificação RÁPIDA usando um INDEX.

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

É um pouco mais complicado (e eu não tenho uma alça de 100%), mas basicamente o Custo é uma função da CPU e IO custo, e a Cardinalidade é o número de linhas Oracle espera analisar.A redução de ambos é uma coisa boa.

Não se esqueça que o custo de uma consulta pode ser influenciado por sua consulta e pelo modelo de otimizador Oracle (por exemplo: COST, ESCOLHA 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:

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

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

5
Mark Nold

Procurar coisas como varreduras seqüenciais pode ser um pouco ú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 é olhar para o real execução . No Postgres, essa é a diferença entre EXPLAIN e EXPLAIN ANALYZE. EXPLAIN ANALYZE realmente executa a consulta e obtém informações reais de tempo para cada nó. Isso permite que você veja o que está realmente acontecendo , em vez do que o planejador pensa acontecerá. Muitas vezes, você descobrirá que uma varredura seqüencial não é um problema; é outra coisa na consulta.

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

4
decibel

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

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

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

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

3
EvilTeach

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

2
Tom Leys

Um "Ah, não, isso não está certo" geralmente está na forma de varredura de tabela. As varreduras de tabela não utilizam índices especiais e podem contribuir para a limpeza de todos os úteis nos caches de memória. 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 para, digamos, usar um índice para consultar as linhas. No entanto, esse é um daqueles padrões de bandeira vermelha que você parece estar procurando.

2
convex hull

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

Por exemplo, se você estiver juntando duas tabelas, A e B em suas respectivas colunas C e D (AC = BD), e seu plano mostrará uma verificação de índice em cluster (termo do SQL Server - não tenho certeza do termo Oracle) na tabela A, em seguida, um loop aninhado se junta a uma série de pesquisas de índice em cluster 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 (sobre os í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 esse padrão de junção ou um índice que realmente não existe.

2
Jonathan Rupp

observe a porcentagem de tempo gasto em cada subseção do plano e considere o que o mecanismo está fazendo. por exemplo, se estiver varrendo uma tabela, considere colocar um índice nos campos que está varrendo

1
Steven A. Lowe

Eu procuro principalmente varreduras de índice ou tabela. Isso geralmente me diz que estou perdendo um índice em uma coluna importante que está na instrução where ou join.

De http://www.sql-server-performance.com/tips/query_execution_plan_analysis_p1.aspx :

Se você vir algum dos itens a seguir em um plano de execução, considere os sinais de alerta e investigue-os quanto a possíveis problemas de desempenho. Cada um deles não é o ideal da 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á-las, mas quanto mais você puder evitá-las, maior será o desempenho da consulta.

1
dpollock