PolarDB:Transformação de consulta baseada em custo

Pré-requisitos

Antes de usar o CBQT, verifique a versão do seu cluster:

• Versão antiga do CBQT: PolarDB for MySQL 8.0.2, revisão 8.0.2.2.0 ou posterior

• Nova versão do CBQT: PolarDB for MySQL 8.0.2, revisão 8.0.2.2.19 ou posterior

Para verificar a versão da revisão, consulte Consultar a versão do mecanismo.

Como funciona

A transformação de consulta reescreve uma instrução SQL em outra equivalente. Por exemplo:

SELECT *
FROM d1
    JOIN f1 ON d1.c1 = f1.c1
    LEFT JOIN (
        SELECT d2.c2 AS d2_c2, f2.c3 AS f2_c3
        FROM d2, f2
        WHERE d2.c1 = f2.c1
    ) derived
    ON derived.d2_c2 = d1.c2
        AND derived.f2_c3 = f1.c3;

Após a mesclagem de tabela materializada, a consulta torna-se:

SELECT *
FROM d1
    JOIN f1 ON d1.c1 = f1.c1
    LEFT JOIN (d2
        JOIN f2 ON TRUE)
    ON d2.c1 = f2.c1
        AND f2.c3 = f1.c3
        AND d2.c2 = d1.c2;

O MySQL Community Edition aplica essa transformação incondicionalmente com base em regras de equivalência, sem verificar se ela reduz o custo. Se os índices de d1/f1 e d2/f2 não estiverem correlacionados, a mesclagem força cada linha da junção d1-f1 a acionar uma junção d2-f2 separada, o que pode aumentar significativamente o tempo de execução.

O CBQT resolve esse problema ao construir um espaço de estados com todas as combinações possíveis de transformações antes de adotar qualquer uma delas. Para duas transformações candidatas A e B, o espaço de estados contém quatro combinações: Nenhuma, Apenas A, Apenas B e AB. O CBQT estima o custo de execução de cada combinação e seleciona o plano de menor custo.

No exemplo de mesclagem de tabela materializada, o plano de execução após a mesclagem tem a seguinte aparência:

O plano de execução antes da mesclagem apresenta este formato:

A vantagem do plano mesclado depende da correlação entre os índices de d2/f2 e d1/f1, bem como do tamanho do conjunto de resultados da junção. O CBQT calcula ambos os custos e aplica a transformação apenas se houver redução de custo.

Transformações que sempre reduzem o custo são tratadas como baseadas em regras e aplicadas sempre que as condições relevantes forem atendidas.

Conceitos principais

Consulta aninhada e profundidade de aninhamento

Uma consulta aninhada é um bloco de consulta inserido dentro de outro. O bloco interno é a subconsulta (ou consulta interna); o bloco externo é a consulta pai (ou consulta externa). A profundidade de aninhamento corresponde ao número de camadas aninhadas.

Exemplo com profundidade de aninhamento 2:

SELECT * FROM t1 WHERE t1.a IN (SELECT t2.b FROM t2 WHERE t2.c = t1.b);

O operador UNION combina instruções no mesmo nível de aninhamento. A consulta a seguir possui profundidade de aninhamento 3:

SELECT *
FROM t1
WHERE t1.a IN (
    SELECT dt.b
    FROM (
        SELECT b, c FROM t2
        UNION
        SELECT b, c FROM t3
    ) dt
    WHERE dt.c = t1.b
);

Transformação

Processo de reescrita de uma consulta em uma forma equivalente, como a mesclagem de tabela materializada mostrada acima.

Objeto de transformação

Elemento da consulta ao qual uma regra de transformação se aplica. Na mesclagem de tabela materializada, o objeto é a própria tabela materializada. Na transformação de subconsulta para SEMI JOIN, o objeto é a subconsulta.

Iteração

Cada passagem sobre todos os objetos de transformação constitui uma iteração. Após aplicar uma transformação, novos objetos podem se tornar elegíveis para transformações adicionais. Por exemplo, uma subconsulta convertida em tabela materializada pode ser mesclada. O CBQT repete o processo até que nenhuma nova transformação seja possível ou até atingir o limite de iterações.

Ativar e configurar o CBQT

Dois parâmetros controlam o CBQT globalmente:

Versão antiga do CBQT

A versão antiga está disponível a partir da revisão 8.0.2.2.0.

O CBQT pode levar tempo para avaliar todas as combinações no espaço de estados. Para proteger consultas de curta duração, defina um limiar de custo: o CBQT ativa apenas quando o custo estimado da consulta excede cbqt_cost_threshold.

Para subconsultas correlacionadas cujo unnesting o MySQL Community Edition não suporta, a versão antiga remove a correlação usando cláusulas GROUP BY.

Para transformações que o MySQL Community Edition aplica incondicionalmente, você pode optar pela avaliação baseada em custo. O recurso de mesclagem de derivadas é controlado pelo sinalizador derived_merge_cost_based em polar_optimizer_switch.

Nova versão do CBQT

Disponível a partir da revisão 8.0.2.2.19, a nova versão introduz controle mais granular sobre contagem de iterações, profundidade de aninhamento, estratégia de busca e regras individuais de transformação.