Quando trabalhamos com Oracle, um ponto importante para otimizar o desempenho das consultas SQL é entender como orientar o otimizador a escolher determinados planos de execução. É exatamente para isso que servem os hints.

Ao inserir hints (dicas) diretamente na consulta, podemos influenciar o Cost Based Optimizer (CBO) a tomar decisões mais adequadas em situações específicas.

O que são Hints?

Os hints são instruções especiais escritas em comentários dentro de uma consulta SQL, que afetam o plano de execução escolhido pelo Oracle. O formato geral é:

SELECT /*+ HINT_EXEMPLO */ coluna1, coluna2
FROM tabela
WHERE condicao;

• Comentário especial: O Oracle reconhece a estrutura /*+ ... */ após o SELECT.
• Case sensitive: Tecnicamente, o texto do hint não faz distinção entre maiúsculas e minúsculas, mas é fundamental que a sintaxe e o nome do hint estejam corretos para que ele seja reconhecido.
• Uso do CBO: Qualquer hint (exceto o RULE) instrui o Oracle a usar o Cost Based Optimizer. Se a sintaxe do hint estiver incorreta, ele é simplesmente ignorado.

A

AND_EQUAL

• Função: Força o otimizador a fazer um “merge scan” de vários índices de coluna única.
• Sintaxe: AND_EQUAL(tabela índice1 índice2 ...)
• Status: Depreciado no Oracle 10g e versões posteriores.

APPEND

• Função: Em instruções INSERT, faz uma inserção em direct path, ignorando espaço livre no bloco. Pode reduzir o volume de redo gerado quando a tabela está em modo NOLOGGING.
• Sintaxe: INSERT /*+ APPEND */ INTO tabela ...
• Observação: Exige que a tabela não seja indexada de forma a impedir o uso de bulk inserts, e que não haja triggers ou constraints que impeçam direct path load.
• Status: Suportado em várias versões. Continua válido.

APPEND_VALUES

• Função: Similar ao APPEND, mas para instruções INSERT ... VALUES, introduzido em versões mais recentes (por volta do Oracle 12c+).
• Sintaxe: INSERT /*+ APPEND_VALUES */ INTO tabela VALUES (...)
• Observação: Otimiza a inserção de linhas únicas em modo de direct path. Útil quando não se está usando INSERT SELECT.

ALL_ROWS

• Função: Otimiza a consulta para melhor throughput (menor consumo total de recursos).
• Sintaxe: SELECT /*+ ALL_ROWS */ ...
• Status: Válido e muito comum.

B

BITMAP

• Função: Força o uso de um índice Bitmap para acessar a tabela.
• Sintaxe: BITMAP(tabela índice_bitmap)
• Status: Em algumas versões é considerado obsoleto ou pouco suportado, pois a detecção automática de bitmap normalmente funciona bem.

C

CACHE / NOCACHE

• Função: Controla como os blocos lidos são colocados no Buffer Cache em caso de full table scan.
• Sintaxe: CACHE(tabela) / NOCACHE(tabela)

CHOOSE

• Função: Permite ao otimizador escolher entre rule-based e cost-based baseado na presença de estatísticas.
• Sintaxe: SELECT /*+ CHOOSE */ ...
• Status: Muito antigo, raramente usado hoje. A partir do 10g, o Oracle praticamente só usa CBO.

CLUSTER

• Função: Força um cluster scan para a tabela.
• Sintaxe: CLUSTER(tabela)

CURSOR_SHARING_EXACT

• Função: Desativa a substituição de literais por binds, mesmo que CURSOR_SHARING esteja habilitado no banco.
• Sintaxe: SELECT /*+ CURSOR_SHARING_EXACT */ ...

CARDINALITY

• Função: Informa ao otimizador uma estimativa do número de linhas esperadas da tabela ou subquery.
• Sintaxe: CARDINALITY(tabela ou subquery, linhas)
• Observação: Pode ser útil quando as estatísticas não representam corretamente o volume real de dados.

D

DISTRIBUTE / DISTRIBUTE_JOIN

• Função: Força a distribuição específica no join paralelo, semelhante ao PQ_DISTRIBUTE, mas usado principalmente em ambientes Exadata ou ambientes paralelos sofisticados.
• Sintaxe: DISTRIBUTE_JOIN(tabela, método)
• Observação: Os métodos mais comuns são BROADCAST, PARTITION, NONE.

DRIVING_SITE

• Função: Em ambientes distribuídos, força a execução remota de parte da query em um site específico.
• Sintaxe: SELECT /*+ DRIVING_SITE(tabela_ou_alias) */ ...

DYNAMIC_SAMPLING

• Função: Controla a coleta de estatísticas dinâmicas em tempo de compilação para melhorar estimativas de seletividade.
• Sintaxe: DYNAMIC_SAMPLING(nível) ou DYNAMIC_SAMPLING(tabela, nível)
• Valores: De 0 a 11. Quanto maior, mais esforço (e potencial custo de compilação) para coletar estatísticas. (11 não é documentado , mas ele trabalha como AUTO, legal né? mas trabalha mal.)

E

EXPAND_GSET_TO_UNION

• Função: Força a expansão de conjuntos (GROUPING SETS) para instruções UNION ALL.
• Status: Depreciado no Oracle 10g.

F

FACT / NO_FACT

• Função: Em star transformations, indica se a tabela é ou não considerada fact table.
• Sintaxe: FACT(tabela) / NO_FACT(tabela)

FIRST_ROWS(n)

• Função: Otimiza para resposta rápida dos primeiros n registros.
• Sintaxe: SELECT /*+ FIRST_ROWS(10) */ ...

FULL

• Função: Força um full table scan na tabela especificada.
• Sintaxe: FULL(tabela)

G

GATHER_PLAN_STATISTICS

• Função: Faz o Oracle coletar estatísticas detalhadas de execução para aquela query, que podem ser visualizadas com DBMS_XPLAN.DISPLAY_CURSOR.
• Sintaxe: SELECT /*+ GATHER_PLAN_STATISTICS */ ...

H

HASH

• Função: Força hash scan (normalmente para tabelas em clusters hash).
• Sintaxe: HASH(tabela)

HASH_AJ

• Função: Transforma subconsulta NOT IN em hash anti-join.
• Sintaxe: HASH_AJ(tabela)
• Status: Depreciado no 10g.

HASH_SJ

• Função: Força hash semi-join ou hash anti-join.
• Sintaxe: HASH_SJ(tabela)
• Status: Antigo e pouco utilizado em versões modernas.

I

INDEX

• Função: Força o uso de um índice específico ou conjunto de índices.
• Sintaxe: INDEX(tabela índice) ou INDEX(tabela índice1 índice2 ...)

INDEX_ASC / INDEX_DESC

• Função: Força index range scan em ordem ascendente ou descendente.
• Sintaxe: INDEX_ASC(tabela índice) / INDEX_DESC(tabela índice)

INDEX_COMBINE

• Função: Força o otimizador a usar uma combinação de índices Bitmap.
• Sintaxe: INDEX_COMBINE(tabela índice1 índice2 ...)

INDEX_FFS

• Função: Força fast full index scan, em vez de full table scan.
• Sintaxe: INDEX_FFS(tabela índice)

INDEX_JOIN

• Função: Força o index join de várias combinações de índices para cobrir todas as colunas necessárias.
• Sintaxe: INDEX_JOIN(tabela índice1 índice2 ...)

INDEX_SS / INDEX_SS_ASC / INDEX_SS_DESC

• Função: Força (ou impede) o index skip scan em ordem ascendente/descendente.
• Status: Oracle 10g+.
• Sintaxe: INDEX_SS(tabela índice), INDEX_SS_ASC(tabela índice), INDEX_SS_DESC(tabela índice)

NO_INDEX / NO_INDEX_FFS / NO_INDEX_SS

• Função: Desabilitam uso de índice em geral, fast full index scan ou skip scan, respectivamente.
• Sintaxe: NO_INDEX(tabela índice), NO_INDEX_FFS(tabela), NO_INDEX_SS(tabela índice)

INVISIBLE (NO_USE_INVISIBLE_INDEXES / USE_INVISIBLE_INDEXES)

• Função: Controla se o Otimizador pode ou não considerar índices marcados como invisíveis.
• Sintaxe: USE_INVISIBLE_INDEXES / NO_USE_INVISIBLE_INDEXES
• Status: Disponível a partir do Oracle 11g R2+ (quando índices invisíveis foram introduzidos).

L

LEADING

• Função: Define a tabela ou a sequência de tabelas que o Oracle deve usar primeiro em joins.
• Sintaxe: LEADING(t1 t2 t3 ...)

M

MERGE

• Função: Força a fusão de views no plano de execução.
• Sintaxe: MERGE(tabela/view)

MERGE_AJ

• Função: Transforma subconsulta NOT IN em merge anti-join.
• Status: Depreciado no 10g.

MONITOR / NO_MONITOR

• Função: Ativa ou desativa o monitoramento de query em tempo de execução (para V$SQL_MONITOR).
• Sintaxe: SELECT /*+ MONITOR */ ... ou SELECT /*+ NO_MONITOR */ ...
• Status: Introduzido no Oracle 11g para melhor monitoramento de SQL em tempo real.

N

NL_AJ / NL_SJ

• Função: Forçam nested loop anti-join ou nested loop semi-join.
• Status: Obsoletos em algumas versões.

NO_EXPAND

• Função: Impede a expansão de consultas com OR ou IN-lists em UNION ALL.
• Sintaxe: SELECT /*+ NO_EXPAND */ ...

NO_MERGE

• Função: Impede a fusão de views.
• Sintaxe: NO_MERGE(tabela/view)

NO_PARALLEL / NOPARALLEL

• Função: Desativa a execução paralela, mesmo que a tabela tenha atributo PARALLEL.
• Sintaxe: NO_PARALLEL(tabela)

NO_PARALLEL_INDEX

• Função: Evita parallel index scan.
• Sintaxe: NO_PARALLEL_INDEX(tabela índice)

NO_PUSH_PRED / NO_PUSH_SUBQ

• Função: Impede que predicados ou subconsultas sejam “empurrados” para etapas anteriores do plano de execução.
• Sintaxe: NO_PUSH_PRED, NO_PUSH_SUBQ

NO_QUERY_TRANSFORMATION

• Função: Desabilita transformações internas de consulta (por exemplo, unnesting, etc.).
• Sintaxe: NO_QUERY_TRANSFORMATION

NO_REWRITE / NOREWRITE

• Função: Desabilita o uso de materialized views para reescrever a query.
• Sintaxe: NO_REWRITE (renomeado a partir de NOREWRITE no 10g)

NO_STAR_TRANSFORMATION

• Função: Impede que o otimizador faça a transformação star.
• Sintaxe: NO_STAR_TRANSFORMATION

NO_USE_HASH / NO_USE_MERGE / NO_USE_NL

• Função: Forçam o otimizador a não usar hash join, merge join ou nested loops.
• Sintaxe: NO_USE_HASH(tabela), NO_USE_MERGE(tabela), NO_USE_NL(tabela)

NOCACHE

• Ver CACHE / NOCACHE.

NOAPPEND

• Função: Desabilita inserção via direct path, mesmo se APPEND estiver setado como default.
• Sintaxe: NOAPPEND

O

OPT_PARAM

• Função: Altera parâmetros de otimização apenas para aquela query (como se fosse um session-level hint).
• Exemplo: SELECT /*+ OPT_PARAM('_optimizer_cost_based_transformation' 'off') */ ...
• Status: Útil para tunar consultas sem alterar parâmetros de todo o banco.

ORDERED

• Função: Faz o Oracle fazer joins na ordem em que as tabelas aparecem no FROM.
• Sintaxe: ORDERED

ORDERED_PREDICATES

• Função: Solicita que o Oracle avalie os predicados na ordem que aparecem na cláusula WHERE.
• Status: Depreciado no 10g.

P

PARALLEL

• Função: Ativa a execução paralela para a tabela especificada. Pode receber grau de paralelismo.
• Sintaxe: PARALLEL(tabela, DOP) ou PARALLEL(tabela, DEFAULT)

PQ_DISTRIBUTE

• Função: Controla a distribuição de linhas entre slaves no join paralelo.
• Sintaxe: PQ_DISTRIBUTE(tabela, método_produtor, método_consumidor)

PUSH_PRED / PUSH_SUBQ

• Função: Forçam o “empurrão” de predicados ou subconsultas para etapas anteriores do plano.
• Sintaxe: PUSH_PRED, PUSH_SUBQ

Q

QB_NAME

• Função: Nomeia um bloco de consulta (query block) para efeitos de análise e aplicação de outros hints.
• Sintaxe: SELECT /*+ QB_NAME(meu_bloco) */ ...

R

REWRITE

• Função: Força a reescrita da consulta usando materialized views disponíveis (independente do custo).
• Sintaxe: REWRITE

RESULT_CACHE / NO_RESULT_CACHE

• Função: Faz caching do resultado da query (ou impede caching) no Query Result Cache.
• Sintaxe: SELECT /*+ RESULT_CACHE */ ... ou SELECT /*+ NO_RESULT_CACHE */ ...
• Status: Disponível a partir do 11g para frente, se o result cache estiver habilitado.

ROWID

• Função: Força acesso via ROWID na tabela especificada.
• Sintaxe: ROWID(tabela)
• Status: Depreciado no 10g.

RULE

• Função: Força o uso do Rule-Based Optimizer. Ignora quaisquer outros hints.
• Status: Obsoleto a partir do 10g (Oracle praticamente não usa mais RBO).

S

SPREAD_MIN_ANALYSIS

• Função: Reduz algumas otimizações de planilha interna, focando em análises mínimas.
• Status: Oracle 10g+.

STAR

• Função: Força a tabela maior a ser joinada por último usando nested loops em índices.
• Status: Depreciado no 10g.

STAR_TRANSFORMATION

• Função: Permite o melhor plano gerado via transformação star.
• Sintaxe: STAR_TRANSFORMATION

SWAP_JOIN_INPUTS

• Função: Instrui o otimizador a inverter a ordem das tabelas no join, trocando o lado do driver e driven na operação de join
• Sintaxe: SWAP_JOIN_INPUTS(tabela)
• Observação: Pode melhorar o desempenho quando a ordem natural de join do otimizador não é a ideal.

SWAP_JOIN_INPUTS_AJ

• Função: Similar ao SWAP_JOIN_INPUTS, mas aplicado para anti-joins. (subqueries transformadas em NOT EXISTS ou JOIN anti-join).
• Sintaxe: SWAP_JOIN_INPUTS_AJ(tabela)

U

UNNEST / NO_UNNEST

• Função: Controlam a “descompactação” (unnesting) de subconsultas, transformando-as em joins.
• Sintaxe: UNNEST ou NO_UNNEST

USE_SEMI

• Função: Força o otimizador a usar semi-joins (subqueries transformadas em EXISTS ou JOIN com filtragem).
• Sintaxe: USE_SEMI(tabela)

USE_CONCAT

• Função: Converte condições OR em um UNION ALL.
• Sintaxe: SELECT /*+ USE_CONCAT */ ...

USE_ANTI

• Função: Força o otimizador a usar anti-joins (subqueries transformadas em NOT EXISTS ou JOIN anti-join).
• Sintaxe: USE_ANTI(tabela)

USE_HASH / USE_MERGE / USE_NL

• Função: Forçam o uso de hash join, merge join ou nested loops para as tabelas especificadas.
• Sintaxe: USE_HASH(tabela1 tabela2), USE_MERGE(tabela1 tabela2), USE_NL(tabela1 tabela2)

Dica sobre a Dica..

1. Versão do Oracle: Alguns hints surgiram ou foram removidos em certas versões. Sempre verifique a documentação da sua versão específica (10g, 11g, 12c, 18c, 19c, 21c, etc.).
2. Sintaxe Exata: Um simples erro de ortografia (por exemplo, esquecer o “+” em /*+ ... */, escrever INDEXS em vez de INDEX) faz o Oracle ignorar completamente o hint.
3. Estatísticas Atualizadas: O Cost Based Optimizer (CBO) funciona melhor com estatísticas de tabelas e índices coerentes. Sem elas, mesmo os hints podem produzir resultados inconsistentes.
4. Ferramentas de Análise:
   • Use EXPLAIN PLAN e DBMS_XPLAN.DISPLAY (ou DBMS_XPLAN.DISPLAY_CURSOR) para verificar se o hint foi aplicado e qual foi o plano de execução.
   • Verifique também colunas como NOTE que podem indicar se houve “unrecognized hint” ou “hint ignored”.
5. Relevância:
   • Alguns hints (especialmente os marcados como dep. ou deprecated) podem não ter efeito.
   • Muitos hints antigos foram substituídos por melhorias automáticas no CBO nas versões recentes.
6. Testes A/B: Sempre compare o plano de execução com e sem o hint. Às vezes, o otimizador padrão pode ser melhor do que forçar um caminho específico.
7. Documentação Oficial: Consulte o capítulo “Hints” do Oracle Database SQL Tuning Guide para sua versão.

Boa consulta e bons tunings!

Se você vem do mundo MySQL, PostgreSQL ou até mesmo Oracle, pode já ter se perguntado: como capturar queries lentas no SQL Server?

No MySQL, temos o slow_query_log , no PostgreSQL, o pg_stat_statements/ slowquery e Oracle AWR/ASH* podem ajudar. Mas e no SQL Server?

Podemos analisar queries em execução no momento utilizando sys.dm_exec_requests, mas e se quisermos consultar o histórico?

Err.. Dai habilitamos o Query Store!

Uma boa solução o Query Store. Ele permite armazenar e analisar estatísticas de execução de queries ao longo do tempo. No entanto, dependendo do volume de dados e da granularidade desejada, ele pode não ser a melhor opção para um monitoramento detalhado.

Foi nesse contexto que pesquisei alternativas e encontrei uma solução eficiente: o uso de Extended Events (XEvents). Se você também busca uma forma confiável de capturar queries lentas no SQL Server, este artigo é para você.

Referências:

• Documentação oficial da Microsoft sobre Query Store
• Blog do Dirceu Resende

Monitorando Queries Lentas com Extended Events

A partir do SQL Server 2012, os Extended Events (XEvents) se tornaram uma das melhores formas de capturar eventos internos do SQL Server. Eles funcionam como um sistema de auditoria leve e personalizável, permitindo registrar queries lentas, deadlocks, commits e por ai vai..

Podemos compará-los a triggers, mas ao invés de serem executados em nível de tabela, eles capturam eventos no nível da instância do SQL Server.

Extended Events (XEvents)

1º Criar o Evento de Captura

Antes de tudo, precisamos criar um evento de captura para registrar as queries demoradas. Para isso, utilizaremos o Extended Events, garantindo que os arquivos de saída sejam gravados em um diretório onde o SQL Server tenha permissão de escrita, no meu caso.

K:\SLOW_QUERIES

CREATE EVENT SESSION [SLOW_QUERIES] ON SERVER  
ADD EVENT sqlserver.sql_batch_completed (  
    ACTION (  
        sqlserver.session_id,  
        sqlserver.client_app_name,  
        sqlserver.client_hostname,  
        sqlserver.database_name,  
        sqlserver.username,  
        sqlserver.session_nt_username,  
        sqlserver.session_server_principal_name,  
        sqlserver.sql_text  
    )  
    WHERE duration > 5000000  -- AJUSTE O TEMPO CONFORME SUA NECESSIDADE
)  
ADD TARGET package0.event_file (  
    SET filename = N'K:\SLOW_QUERIES\slow.xel',   -- AQUI TAMBEM, AJUSTE SEU DIRETORIO
        max_file_size = 10,  
        max_rollover_files = 10  
)  
WITH (STARTUP_STATE = ON);  
GO  

-- Ativa o Extended Event
ALTER EVENT SESSION [SLOW_QUERIES] ON SERVER STATE = START
GO

neste caso iremos coletar tudo que for acima de 5 segundos , com 10 arquivos de no maximo 10MB, em D:\SLOW_QUERIES\.

2º Criar uma Tabela para salvar estes dados

Agora, precisamos de um local para armazenar os dados coletados pelo XEvents. Criamos uma tabela que receberá as informações capturadas.

CREATE TABLE dbo.Historico_Query_Lenta (
    [Dt_Evento] DATETIME,
    [session_id] INT,
    [database_name] VARCHAR(128),
    [username] VARCHAR(128),
    [session_server_principal_name] VARCHAR(128),
    [session_nt_username] VARCHAR(128),
    [client_hostname] VARCHAR(128),
    [client_app_name] VARCHAR(128),
    [duration] DECIMAL(18, 2),
    [cpu_time] DECIMAL(18, 2),
    [logical_reads] BIGINT,
    [physical_reads] BIGINT,
    [writes] BIGINT,
    [row_count] BIGINT,
    [sql_text] XML,
    [batch_text] XML,
    [result] VARCHAR(100)
) WITH(DATA_COMPRESSION=PAGE)
GO

3º Criar uma Procedure para Captura dos Dados

O próximo passo é criar uma Stored Procedure para extrair os dados do Extended Events e armazená-los na tabela criada no Passo 2, crie um database de sua escolha , recomendo a ter sempre um database administrativo para tais acoes.

 
CREATE PROCEDURE dbo.stpCarga_Query_Lenta
AS
BEGIN
    
    
    DECLARE 
        @TimeZone INT = DATEDIFF(HOUR, GETUTCDATE(), GETDATE()),
        @Dt_Ultimo_Registro DATETIME = ISNULL((SELECT MAX(Dt_Evento) FROM dbo.Historico_Query_Lenta), '1900-01-01')
 
 
    IF (OBJECT_ID('tempdb..#Eventos') IS NOT NULL) DROP TABLE #Eventos
    ;WITH CTE AS (
        SELECT CONVERT(XML, event_data) AS event_data
        FROM sys.fn_xe_file_target_read_file(N'K:\SLOW_QUERIES\slow*.xel', NULL, NULL, NULL)
    )
    SELECT
        DATEADD(HOUR, @TimeZone, CTE.event_data.value('(//event/@timestamp)[1]', 'datetime')) AS Dt_Evento,
        CTE.event_data
    INTO
        #Eventos
    FROM
        CTE
    WHERE
        DATEADD(HOUR, @TimeZone, CTE.event_data.value('(//event/@timestamp)[1]', 'datetime')) > @Dt_Ultimo_Registro
    
 
    INSERT INTO dbo.Historico_Query_Lenta
    SELECT
        A.Dt_Evento,
        xed.event_data.value('(action[@name="session_id"]/value)[1]', 'int') AS session_id,
        xed.event_data.value('(action[@name="database_name"]/value)[1]', 'varchar(128)') AS [database_name],
        xed.event_data.value('(action[@name="username"]/value)[1]', 'varchar(128)') AS username,
        xed.event_data.value('(action[@name="session_server_principal_name"]/value)[1]', 'varchar(128)') AS session_server_principal_name,
        xed.event_data.value('(action[@name="session_nt_username"]/value)[1]', 'varchar(128)') AS [session_nt_username],
        xed.event_data.value('(action[@name="client_hostname"]/value)[1]', 'varchar(128)') AS [client_hostname],
        xed.event_data.value('(action[@name="client_app_name"]/value)[1]', 'varchar(128)') AS [client_app_name],
        CAST(xed.event_data.value('(//data[@name="duration"]/value)[1]', 'bigint') / 1000000.0 AS NUMERIC(18, 2)) AS duration,
        CAST(xed.event_data.value('(//data[@name="cpu_time"]/value)[1]', 'bigint') / 1000000.0 AS NUMERIC(18, 2)) AS cpu_time,
        xed.event_data.value('(//data[@name="logical_reads"]/value)[1]', 'bigint') AS logical_reads,
        xed.event_data.value('(//data[@name="physical_reads"]/value)[1]', 'bigint') AS physical_reads,
        xed.event_data.value('(//data[@name="writes"]/value)[1]', 'bigint') AS writes,
        xed.event_data.value('(//data[@name="row_count"]/value)[1]', 'bigint') AS row_count,
        TRY_CAST(xed.event_data.value('(//action[@name="sql_text"]/value)[1]', 'varchar(max)') AS XML) AS sql_text,
        TRY_CAST(xed.event_data.value('(//data[@name="batch_text"]/value)[1]', 'varchar(max)') AS XML) AS batch_text,
        xed.event_data.value('(//data[@name="result"]/text)[1]', 'varchar(100)') AS result
    FROM
        #Eventos A
        CROSS APPLY A.event_data.nodes('//event') AS xed (event_data)
 
 
END

4º Criar um Job para coletas frequentes.

Para garantir que a coleta de queries lentas ocorra de forma contínua, podemos configurar um SQL Server Agent Job para executar a stored procedure periodicamente.

Então podemos consultar nossa tabela Historico_Query_Lenta onde estarão nossos dados.

Seguindo a parte 2 do artigo sobre Execution Plan (planos de execução), veremos como é o funcionamento da analise e interpretação de um plano de execução no banco de dados POSTGRESQL.

Seguindo o que comumente faço para essa analise, 2 modos podemos estabelecer para essa analise :

1. Plano de execução em modo texto/tabular, onde é visto de forma indentada os steps.
2. Plano de execução em modo tree (arvore), onde é visto de forma grafica os steps.

Similar ao oracle database, o POSTGRESQL utilize a seguinte metodologia para interpretação de planos de execução, O plano de execução é lido de baixo para cima e da direita para a esquerda, refletindo a sequência em que o PostgreSQL executa as operações.

No PostgreSQL, os planos de execução são lidos de baixo para cima e da direita para a esquerda. Isso significa que:

• A operação mais profunda (mais aninhada) no plano é a primeira a ser executada.
• As operações externas ou superiores são executadas posteriormente, processando os dados obtidos das operações inferiores.

Essa abordagem permite entender melhor o fluxo da execução da consulta e identificar possíveis gargalos de desempenho.

Para tornar a explicação mais objetiva, vamos analisar um exemplo de query, interpretar seu plano de execução e, posteriormente, verificar possíveis otimizações para tornar a execução do SQL mais eficiente.

 SELECT * FROM (
    (SELECT
        poi.supplier_product ->> 'supplier_product_name' AS name,
        poi.price AS price,
        poi.created_at AS expires_at,
        poi.supplier_product ->> 'supplier_product_manufacturer' AS manufacturer,
        poi.supplier_product ->> 'supplier_product_packing' AS packing,
        poi.supplier_product ->> 'supplier_product_pack_quantity' AS pack_quantity,
        poi.supplier_product ->> 'supplier_product_unit_purchase' AS unit_purchase,
        poi.confirmed_quantity AS quantity_price,
        sp.name AS name_supply,
        sp.identifier AS identifier_supply,
        1 AS order_by
    FROM purchase_order_items poi
    INNER JOIN purchase_orders po ON po.id = poi.purchase_order_id
    INNER JOIN buyer_products bp ON bp.buyer_id = po.buyer_id AND
        bp.code = poi.buyer_product ->> 'buyer_product_code'
    INNER JOIN products p ON p.id = bp.base_product_id
    INNER JOIN suppliers sp ON sp.id = po.supplier_id
    WHERE bp.id = 12081956
        AND poi.created_at < '2025-02-21 16:57:59.225571'
    ORDER BY poi.created_at DESC
    LIMIT 3
    )
    UNION ALL
    (SELECT
        bp.name,
        bp.source_price AS price,
        bp.created_at AS expires_at,
        '' AS manufacturer,
        '' AS packing,
        '' AS pack_quantity,
        '' AS unit_purchase,
        0 AS quantity_price,
        '' AS name_supply, 
        '' AS identifier_supply,
        2 AS order_by
    FROM public.buyer_products bp
    INNER JOIN public.products p ON p.id = bp.base_product_id
    WHERE bp.id = 12081956
        AND bp.source_price IS NOT NULL
    )
) b
ORDER BY order_by
LIMIT 3;

Para analisar os planos de execução, utilizaremos duas ferramentas que auxiliam na visualização e interpretação dos dados. Cada ferramenta apresenta o plano de uma forma diferente, permitindo uma análise mais completa:

1. Modo Tabular: Explain Depesz – Exibe o plano de execução em formato tabular, facilitando a leitura estruturada dos passos.
   https://explain.depesz.com/
   
   
2. Modo Árvore (Tree): Explain Dalibo – Representa o plano de execução graficamente, tornando mais intuitiva a hierarquia das operações.
   https://explain.dalibo.com/

Instrução: Clique nos links acima para acessar as ferramentas e seguir o procedimento de visualização dos dois métodos.

Para visualizar o plano de execução em ambos os modos, primeiro precisamos extraí-lo em formato de texto. Para isso, basta adicionar a seguinte declaração no início da query:

EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS)
(...) SQL CODE (...)

Essa instrução fornece informações detalhadas sobre a execução da consulta, incluindo:

• ANALYZE: Executa a query de fato e retorna estatísticas reais de tempo e quantidade de linhas processadas.
• COSTS: Exibe os custos estimados de cada operação no plano de execução.
• VERBOSE: Apresenta detalhes adicionais, como a estrutura da consulta e a relação das colunas envolvidas.
• BUFFERS: Mostra informações sobre o uso do cache de memória (buffers) durante a execução.

Abaixo, veja como o código SQL completo ficará com a inclusão do EXPLAIN na consulta.

 EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS )
 SELECT * FROM (
    (SELECT
        poi.supplier_product ->> 'supplier_product_name' AS name,
        poi.price AS price,
        poi.created_at AS expires_at,
        poi.supplier_product ->> 'supplier_product_manufacturer' AS manufacturer,
        poi.supplier_product ->> 'supplier_product_packing' AS packing,
        poi.supplier_product ->> 'supplier_product_pack_quantity' AS pack_quantity,
        poi.supplier_product ->> 'supplier_product_unit_purchase' AS unit_purchase,
        poi.confirmed_quantity AS quantity_price,
        sp.name AS name_supply,
        sp.identifier AS identifier_supply,
        1 AS order_by
    FROM purchase_order_items poi
    INNER JOIN purchase_orders po ON po.id = poi.purchase_order_id
    INNER JOIN buyer_products bp ON bp.buyer_id = po.buyer_id AND
        bp.code = poi.buyer_product ->> 'buyer_product_code'
    INNER JOIN products p ON p.id = bp.base_product_id
    INNER JOIN suppliers sp ON sp.id = po.supplier_id
    WHERE bp.id = 12081956
        AND poi.created_at < '2025-02-21 16:57:59.225571'
    ORDER BY poi.created_at DESC
    LIMIT 3
    )
    UNION ALL
    (SELECT
        bp.name,
        bp.source_price AS price,
        bp.created_at AS expires_at,
        '' AS manufacturer,
        '' AS packing,
        '' AS pack_quantity,
        '' AS unit_purchase,
        0 AS quantity_price,
        '' AS name_supply, 
        '' AS identifier_supply,
        2 AS order_by
    FROM public.buyer_products bp
    INNER JOIN public.products p ON p.id = bp.base_product_id
    WHERE bp.id = 12081956
        AND bp.source_price IS NOT NULL
    )
) b
ORDER BY order_by
LIMIT 3;

Após executar o comando EXPLAIN, o PostgreSQL gera um plano de execução em formato de texto. A seguir, veja um exemplo do plano gerado para esta query:

 Limit  (cost=120200.56..120200.57 rows=2 width=252) (actual time=207.212..207.217 rows=3 loops=1)
   Output: ((poi.supplier_product ->> 'supplier_product_name'::text)), poi.price, poi.created_at, ((poi.supplier_product ->> 'supplier_product_manufacturer'::text)), ((poi.supplier_product ->> 'supplier_product_packing'::t
ext)), ((poi.supplier_product ->> 'supplier_product_pack_quantity'::text)), ((poi.supplier_product ->> 'supplier_product_unit_purchase'::text)), poi.confirmed_quantity, sp.name, sp.identifier, (1)
   Buffers: shared hit=64032
   ->  Sort  (cost=120200.56..120200.57 rows=2 width=252) (actual time=186.714..186.718 rows=3 loops=1)
         Output: ((poi.supplier_product ->> 'supplier_product_name'::text)), poi.price, poi.created_at, ((poi.supplier_product ->> 'supplier_product_manufacturer'::text)), ((poi.supplier_product ->> 'supplier_product_packi
ng'::text)), ((poi.supplier_product ->> 'supplier_product_pack_quantity'::text)), ((poi.supplier_product ->> 'supplier_product_unit_purchase'::text)), poi.confirmed_quantity, sp.name, sp.identifier, (1)
         Sort Key: (1)
         Sort Method: quicksort  Memory: 25kB
         Buffers: shared hit=64032
         ->  Append  (cost=120195.05..120200.49 rows=2 width=252) (actual time=186.639..186.704 rows=4 loops=1)
               Buffers: shared hit=64032
               ->  Limit  (cost=120195.05..120195.06 rows=1 width=242) (actual time=186.637..186.640 rows=3 loops=1)
                     Output: ((poi.supplier_product ->> 'supplier_product_name'::text)), poi.price, poi.created_at, ((poi.supplier_product ->> 'supplier_product_manufacturer'::text)), ((poi.supplier_product ->> 'supplier_p
roduct_packing'::text)), ((poi.supplier_product ->> 'supplier_product_pack_quantity'::text)), ((poi.supplier_product ->> 'supplier_product_unit_purchase'::text)), poi.confirmed_quantity, sp.name, sp.identifier, 1
                     Buffers: shared hit=64024
                     ->  Sort  (cost=120195.05..120195.06 rows=1 width=242) (actual time=186.619..186.621 rows=3 loops=1)
                           Output: ((poi.supplier_product ->> 'supplier_product_name'::text)), poi.price, poi.created_at, ((poi.supplier_product ->> 'supplier_product_manufacturer'::text)), ((poi.supplier_product ->> 'supp
lier_product_packing'::text)), ((poi.supplier_product ->> 'supplier_product_pack_quantity'::text)), ((poi.supplier_product ->> 'supplier_product_unit_purchase'::text)), poi.confirmed_quantity, sp.name, sp.identifier, 1
                           Sort Key: poi.created_at DESC
                           Sort Method: top-N heapsort  Memory: 26kB
                           Buffers: shared hit=64024
                           ->  Nested Loop  (cost=2.04..120195.04 rows=1 width=242) (actual time=0.193..186.435 rows=273 loops=1)
                                 Output: (poi.supplier_product ->> 'supplier_product_name'::text), poi.price, poi.created_at, (poi.supplier_product ->> 'supplier_product_manufacturer'::text), (poi.supplier_product ->> 'sup
plier_product_packing'::text), (poi.supplier_product ->> 'supplier_product_pack_quantity'::text), (poi.supplier_product ->> 'supplier_product_unit_purchase'::text), poi.confirmed_quantity, sp.name, sp.identifier, 1
                                 Inner Unique: true
                                 Buffers: shared hit=64024
                                 ->  Nested Loop  (cost=1.75..120194.70 rows=1 width=423) (actual time=0.169..181.896 rows=273 loops=1)
                                       Output: poi.supplier_product, poi.price, poi.created_at, poi.confirmed_quantity, po.supplier_id
                                       Inner Unique: true
                                       Buffers: shared hit=63194
                                       ->  Nested Loop  (cost=1.31..120192.03 rows=1 width=427) (actual time=0.154..181.249 rows=273 loops=1)
                                             Output: poi.supplier_product, poi.price, poi.created_at, poi.confirmed_quantity, po.supplier_id, bp.base_product_id
                                             Join Filter: ((bp.code)::text = (poi.buyer_product ->> 'buyer_product_code'::text))
                                             Rows Removed by Join Filter: 48357
                                             Buffers: shared hit=62374
                                             ->  Nested Loop  (cost=0.87..7304.32 rows=6352 width=19) (actual time=0.037..8.088 rows=9209 loops=1)
                                                   Output: po.id, po.supplier_id, bp.code, bp.base_product_id
                                                   Buffers: shared hit=4649
                                                   ->  Index Scan using buyer_products_pkey on public.buyer_products bp  (cost=0.44..2.68 rows=1 width=15) (actual time=0.016..0.018 rows=1 loops=1)
                                                         Output: bp.id, bp.base_product_id, bp.buyer_id, bp.created_at, bp.updated_at, bp.external_id, bp.name, bp.code, bp.status, bp.source_price, bp.identifier, bp.accept_
alternative_brands, bp.id_scub, bp.internal_scub_id, bp.detailed_description, bp.buyer_product_children
                                                         Index Cond: (bp.id = 12081956)
                                                         Buffers: shared hit=4
                                                   ->  Index Scan using index_purchase_orders_on_buyer_id on public.purchase_orders po  (cost=0.43..7100.53 rows=6704 width=12) (actual time=0.012..6.880 rows=9209 loops=1)
                                                         Output: po.id, po.supplier_id, po.total_price, po.items_count, po.created_at, po.updated_at, po.confirmation_id, po.synchronized_at, po.buyer_id, po.observation, po.
sequence, po.origin_id, po.origin_type, po.external_id, po.redirect_to_legacy, po.name, po.origin_observation, po.opened_at, po.contact, po.terms_and_conditions, po.freight_type, po.minimum_purchase, po.valid_until, po.pay
ment_method_id, po.billing_address, po.uuid, po.created_by, po.created_by_info, po.pending_download, po.text_search_vector, po.request_id, po.upload_id, po.upload_id_gr
                                                         Index Cond: (po.buyer_id = bp.buyer_id)
                                                         Buffers: shared hit=4645
                                             ->  Index Scan using index_purchase_order_items_on_purchase_order_id on public.purchase_order_items poi  (cost=0.44..9.90 rows=225 width=751) (actual time=0.002..0.006 rows=5 lo
ops=9209)
                                                   Output: poi.id, poi.purchase_order_id, poi.created_at, poi.updated_at, poi.status, poi.confirmed_quantity, poi.cancellation, poi.supplier_observation, poi.opening_quantity
, poi.supplier_product, poi.buyer_product, poi.sequence_number, poi.price, poi.comments, poi.origin, poi.uuid, poi.sequence_seller_item_number
                                                   Index Cond: (poi.purchase_order_id = po.id)
                                                   Filter: (poi.created_at < '2025-02-21 16:57:59.225571'::timestamp without time zone)
                                                   Rows Removed by Filter: 0
                                                   Buffers: shared hit=57725
                                       ->  Index Only Scan using products_pkey on public.products p  (cost=0.44..2.68 rows=1 width=4) (actual time=0.002..0.002 rows=1 loops=273)
                                             Output: p.id
                                             Index Cond: (p.id = bp.base_product_id)
                                             Heap Fetches: 0
                                             Buffers: shared hit=820
                                 ->  Index Scan using idx_sp_on_id on public.suppliers sp  (cost=0.29..0.33 rows=1 width=58) (actual time=0.002..0.002 rows=1 loops=273)
                                       Output: sp.id, sp.name, sp.created_at, sp.updated_at, sp.external_id, sp.identifier, sp.identifier_kind, sp.bio_id, sp.synchronized_at, sp.bioid_synchronized_at, sp.phone, sp.plan_nam
e, sp.metadata, sp.is_external
                                       Index Cond: (sp.id = po.supplier_id)
                                       Buffers: shared hit=828
               ->  Subquery Scan on "*SELECT* 2"  (cost=0.87..5.38 rows=1 width=252) (actual time=0.058..0.060 rows=1 loops=1)
                     Output: "*SELECT* 2".name, "*SELECT* 2".price, "*SELECT* 2".expires_at, ''::text, ''::text, ''::text, ''::text, 0, ''::character varying, ''::character varying, 2
                     Buffers: shared hit=8
                     ->  Nested Loop  (cost=0.87..5.34 rows=1 width=262) (actual time=0.054..0.055 rows=1 loops=1)
                           Output: bp_1.name, bp_1.source_price, bp_1.created_at, ''::text, ''::text, ''::text, ''::text, 0, ''::character varying, ''::character varying, 2
                           Inner Unique: true
                           Buffers: shared hit=8
                           ->  Index Scan using idx_bp_on_id_source_price on public.buyer_products bp_1  (cost=0.43..2.67 rows=1 width=66) (actual time=0.013..0.013 rows=1 loops=1)
                                 Output: bp_1.id, bp_1.base_product_id, bp_1.buyer_id, bp_1.created_at, bp_1.updated_at, bp_1.external_id, bp_1.name, bp_1.code, bp_1.status, bp_1.source_price, bp_1.identifier, bp_1.accept_
alternative_brands, bp_1.id_scub, bp_1.internal_scub_id, bp_1.detailed_description, bp_1.buyer_product_children
                                 Index Cond: (bp_1.id = 12081956)
                                 Buffers: shared hit=4
                           ->  Index Only Scan using products_pkey on public.products p_1  (cost=0.44..2.68 rows=1 width=4) (actual time=0.005..0.005 rows=1 loops=1)
                                 Output: p_1.id
                                 Index Cond: (p_1.id = bp_1.base_product_id)
                                 Heap Fetches: 0
                                 Buffers: shared hit=4
 Query Identifier: 273579094919034765
 Planning:
   Buffers: shared hit=129
 Planning Time: 3.160 ms
 JIT:
   Functions: 34
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 1.963 ms, Inlining 0.000 ms, Optimization 0.883 ms, Emission 19.683 ms, Total 22.528 ms
 Execution Time: 209.321 ms
(82 rows)

Assim como no Oracle Database, o PostgreSQL utiliza a indentação, representada pelo símbolo ->, para indicar a ordem de execução das operações, sem atribuir um identificador sequencial a cada passo. Dessa forma, quanto maior a indentação antes do ->, mais interno (ou profundo) é o passo no plano de execução. Isso significa que os passos mais indentados são executados primeiro.

Com o plano de execução em formato de texto, podemos utilizar as duas ferramentas apresentadas para realizar a análise e identificar possíveis gargalos na execução da query. A seguir, exploraremos ambas as abordagens e demonstraremos como detectar os principais pontos de otimização no SQL.


Utilizaremos o plano de execução em formato de texto gerado anteriormente e o submeteremos à ferramenta Explain Depesz, que apresenta a análise no formato tabular. Você pode acessá-la através do seguinte link: Explain Depesz.
https://explain.depesz.com/

Passos para visualizar o plano de execução no Explain Depesz:

• Seta Vermelha: Insira um título para o plano de execução (opcional, mas facilita a organização).
• Seta Verde: Cole o plano de execução gerado em formato de texto.
• Seta Azul: Cole a query utilizada para gerar o plano de execução.
• Seta Preta: Após preencher os campos acima, clique em Submit para processar e visualizar o plano de execução.

Após submeter o plano de execução, observe na demonstração abaixo os principais gargalos identificados. Eles são destacados em laranja e vermelho, indicando as operações mais custosas. Além disso, os trechos grifados representam cláusulas da query que podem ser otimizadas para melhorar o desempenho.

Nested Loop (cost=1.31..120,192.03 rows=1 width=427) (actual time=0.154..181.249 rows=273 loops=1)
Output: poi.supplier_product, poi.price, poi.created_at, poi.confirmed_quantity, po.supplier_id, bp.base_product_id
Join Filter: ((bp.code)::text = (poi.buyer_product ->> ‘buyer_product_code’::text))
Rows Removed by Join Filter: 48,357
Buffers: shared hit=62,374

O que significa?

• O PostgreSQL está executando um Nested Loop Join para combinar os dados das tabelas buyer_products (bp) e purchase_order_items (poi).
• Custo estimado: 120.192 → Indica que esta é uma das etapas mais pesadas do plano.
• Tempo real gasto: 181.249 ms → Isso confirma que essa operação está realmente demorando muito.

Problema identificado:

• O Nested Loop Join pode ser ineficiente, especialmente quando muitas linhas precisam ser comparadas.

Detalhes do Join e o Problema do Filtro

Join Filter: ((bp.code)::text = (poi.buyer_product ->> ‘buyer_product_code’::text))
Rows Removed by Join Filter: 48,357

O que isso significa?

• O PostgreSQL está tentando juntar bp.code com o campo JSON poi.buyer_product ->> 'buyer_product_code'.
• Porém, 48.357 linhas foram lidas e removidas porque não atendiam ao filtro.
  Isso significa que muitos dados desnecessários foram carregados antes da filtragem.

Problema identificado:

• O filtro de comparação JSON é extremamente ineficiente.
• O PostgreSQL precisa percorrer todas as linhas antes de saber quais realmente fazem parte da junção.

Buffers: shared hit=62,374

📌 O que isso significa?

• 62.374 blocos de memória foram acessados no cache do PostgreSQL.
• Isso indica que nenhuma leitura de disco foi necessária, o que é positivo.
• Porém, mesmo sem leituras de disco, a query ainda está lenta, o que mostra que o problema está na lógica da consulta, não apenas no hardware.

Como otimizar essa parte do plano?

Agora que sabemos que o Nested Loop Join e o filtro JSON são os principais problemas, podemos sugerir melhorias:

1⃣ Criar um índice para melhorar a comparação JSON

A comparação (bp.code)::text = (poi.buyer_product ->> 'buyer_product_code'::text) é muito custosa, pois o PostgreSQL precisa processar os dados JSON antes de compará-los.

Solução: Criar um índice funcional no JSON

CREATE INDEX idx_poi_buyer_product_code ON purchase_order_items ((buyer_product ->> 'buyer_product_code'));

CREATE INDEX idx_poi_purchase_order_id_created_at ON purchase_order_items (purchase_order_id, created_at DESC);

Impacto esperado:

• O PostgreSQL poderá usar o índice diretamente para encontrar as correspondências.
• Reduz drasticamente o número de linhas removidas pelo Join Filter.
• Diminui a necessidade de percorrer todas as linhas da tabela.
• Reduz tempo da busca no purchase_order_items.
• Melhora a performance do Nested Loop.

Problemas identificados:

1. Join Filter está descartando muitas linhas (48.357 removidas).
2. Nested Loop Join não é eficiente para grandes volumes de dados.
3. Falta de um índice eficiente para buscas no JSON.
4. Falta de um índice composto no purchase_order_items para junções rápidas.

Melhorias sugeridas:

Criar um índice para otimizar a busca JSON.
Usar um Hash Join em vez de Nested Loop.
Criar um índice composto para melhorar as junções.

Melhoria da Análise e Utilização da Ferramenta EXPLAIN DALIBO

Agora que identificamos os gargalos e propomos soluções, vamos abordar esse problema sob uma nova perspectiva, utilizando a ferramenta EXPLAIN Dalibo.

https://explain.dalibo.com

Observe que a caixa do Nested Loop representa o principal gargalo da query, e o “Join Filter” está relacionado à condição ((bp.code)::text = (poi.buyer_product ->> 'buyer_product_code'::text)), o que indica uma junção ineficiente que impacta diretamente o desempenho da consulta.

Conclusão

Neste trabalho, exploramos duas abordagens para analisar e otimizar uma query SQL no PostgreSQL:

1. EXPLAIN ANALYZE → Fornece um relatório detalhado sobre a execução da query, ajudando a identificar custos, tempo de execução e estatísticas importantes.
2. EXPLAIN Dalibo → Apresenta um formato visual e intuitivo, facilitando a identificação dos pontos críticos da consulta, como Nested Loops, filtros ineficientes e ordenações desnecessárias.

Além disso, aprendemos a identificar gargalos na execução da query, como o Join Filter ineficiente e a ordenção manual sem suporte de índices. Com isso, aplicamos índices estratégicos e sugerimos a troca de algoritmos de junção para melhorar a performance.

O principal aprendizado aqui é que, antes de otimizar uma query, é essencial entender como o PostgreSQL a executa, localizar os gargalos e aplicar ajustes cirúrgicos, como a criação de índices e a escolha do tipo de junção mais eficiente.