O pushdown completo de predicados elimina a filtragem redundante de linhas que o MySQL executa na camada SQL após uma varredura de índice baseada em intervalo. Esse recurso reduz a sobrecarga de computação em consultas de intervalo grandes no PolarDB for MySQL.
Pré-requisitos
Antes de começar, verifique se você tem:
Um cluster PolarDB for MySQL com a versão 8.0
Versão de revisão 8.0.1.1.5 ou posterior, ou 8.0.2.2.0 ou posterior
Para saber como verificar a versão do seu cluster, consulte Consultar a versão da engine.
Como funciona
No MySQL Community Edition, quando uma consulta usa uma condição de intervalo para varrer um índice, a avaliação da condição ocorre duas vezes:
Sem pushdown completo de predicados:
A engine de armazenamento varre o índice com a condição de intervalo e retorna as linhas correspondentes.
A camada SQL filtra novamente as linhas retornadas com a mesma condição de intervalo.
Com pushdown completo de predicados:
A engine de armazenamento varre o índice com a condição de intervalo e retorna as linhas correspondentes.
O sistema descarta a condição de intervalo. A camada SQL ignora a nova filtragem porque a engine de armazenamento já a aplicou.
Essa filtragem duplicada desperdiça recursos de computação. O pushdown completo de predicados remove a passagem redundante de filtro na camada SQL.
Ative o pushdown completo de predicados
Use a variável detach_range_condition do parâmetro loose_optimizer_switch para ativar ou desativar o pushdown completo de predicados. Para mais informações, consulte Especifique parâmetros de cluster e nó.
Verifique com EXPLAIN
Use o campo Extra na saída do EXPLAIN para confirme se o pushdown completo de predicados está ativo:
|
**Valor de |
Significado |
|
|
A camada SQL está refiltrando linhas. O pushdown completo de predicados está desativado. |
|
|
A camada SQL ignora a nova filtragem. O pushdown completo de predicados está ativo. |
Desativado (linha de base)
O exemplo a seguir usa o esquema TPC-H. Com detach_range_condition definido como off, a saída do EXPLAIN exibe Using where. Isso indica que a condição de intervalo é aplicada novamente na camada SQL (TPC-H Q2).
set @@optimizer_switch='detach_range_condition=off';
EXPLAIN SELECT * FROM lineitem WHERE l_orderkey > 10 AND l_orderkey < 60000000 LIMIT 10000000, 10\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: lineitem
partitions: NULL
type: range
possible_keys: PRIMARY,i_l_orderkey,i_l_orderkey_quantity
key: PRIMARY
key_len: 4
ref: NULL
rows: 29720232
filtered: 100.00
Extra: Using where
Ativado
Quando ignore_polar_optimizer_rule está definido como on, o sistema descarta as condições de intervalo após a varredura da engine de armazenamento. A saída do EXPLAIN mostra Using index, o que sinaliza que a camada SQL pula a etapa de refiltragem. Os exemplos abaixo usam TPC-H Q5 e Q6.
Q5
set @@ignore_polar_optimizer_rule=on;
EXPLAIN SELECT COUNT(*) FROM lineitem WHERE l_suppkey > 10 AND l_suppkey < 50000\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: lineitem
partitions: NULL
type: range
possible_keys: i_l_suppkey_partkey,i_l_suppkey
key: i_l_suppkey
key_len: 5
ref: NULL
rows: 29720232
filtered: 100.00
Extra: Using index
Q6
set @@ignore_polar_optimizer_rule=on;
EXPLAIN SELECT COUNT(*) FROM LINEITEM WHERE l_receiptDATE > '1992-01-03' AND l_receiptDATE < '1994-12-31'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: LINEITEM
partitions: NULL
type: range
possible_keys: i_l_receiptdate
key: i_l_receiptdate
key_len: 4
ref: NULL
rows: 29720232
filtered: 100.00
Extra: Using index
Resultados dos testes
A figura a seguir ilustra a diferença de desempenho entre ativar e desativar o pushdown completo de predicados. A medição usou as consultas Q5 e Q6 do TPC-H com fator de escala 10.

Os ganhos reais de desempenho dependem da sua carga de trabalho, distribuição de dados e configuração do cluster. Execute seus próprios benchmarks para avaliar o impacto no seu ambiente.