PolarDB:Optimisation des sous-requêtes

Scénario 1 : Éliminer l'imbrication SELECT redondante

Cas d'application : La sous-requête enveloppe uniquement une fonction d'agrégation ou une expression, sans autre logique complexe.

Modèle de réécriture :

-- Before
SELECT (SELECT SUM(a) FROM t2) FROM dual;

-- After
SELECT SUM(`test`.`t2`.`a`) AS `sum(a)` FROM `test`.`t2`

La même élimination s'applique dans les clauses HAVING, où l'optimiseur aplatit plusieurs niveaux d'imbrication :

-- Before
SELECT SUM(a) FROM t2 HAVING (SELECT(SELECT(SELECT count(b))));

-- After
SELECT SUM(`testdb`.`t2`.`a`) AS `SUM(a)` from `testdb`.`t2` HAVING (0 <> count(`testdb`.`t2`.`b`))

Vérification par l'exemple :

1. Préparez les données de test :

   DROP TABLE IF EXISTS t2;
   CREATE TABLE t2 (
       id INT PRIMARY KEY AUTO_INCREMENT,
       a INT,
       b INT
   );
   INSERT INTO t2 (a, b) VALUES (10, 100), (20, NULL), (50, 200), (120, NULL);

2. Examinez le plan d'exécution sans optimisation :

   SET simplify_subq_mode = 'OFF';
   EXPLAIN SELECT SUM(a) FROM t2 HAVING (SELECT(SELECT(SELECT count(b))));
   SHOW WARNINGS;

   Résultat — quatre niveaux d'imbrication SELECT subsistent :

   /* select#1 */ select sum(`testdb`.`t2`.`a`) AS `SUM(a)` from `testdb`.`t2` having (0 <> (/* select#2 */ select (/* select#3 */ select (/* select#4 */ select count(`testdb`.`t2`.`b`)))))

3. Examinez le plan d'exécution avec l'optimisation activée :

   SET simplify_subq_mode = 'ON';
   EXPLAIN SELECT SUM(a) FROM t2 HAVING (SELECT(SELECT(SELECT count(b))));
   SHOW WARNINGS;

   Résultat — toute imbrication est éliminée :

   /* select#1 */ select sum(`testdb`.`t2`.`a`) AS `SUM(a)` from `testdb`.`t2` having (0 <> count(`testdb`.`t2`.`b`))

Scénario 2 : Pré-évaluer les sous-requêtes [NOT] EXISTS

Cas d'application : L'optimiseur peut déterminer statiquement qu'une sous-requête EXISTS ou NOT EXISTS retourne toujours vrai (non vide) ou faux (vide).

Modèle de réécriture :

-- Non-empty result: EXISTS clause is removed entirely
-- Before
SELECT * FROM t1 WHERE EXISTS(SELECT MAX(a) FROM t2);
-- After
SELECT * FROM t1

-- Empty result (WHERE/HAVING evaluates to false, or LIMIT 0): replaced with false
-- Before
SELECT * FROM t1 WHERE EXISTS(SELECT max(a) FROM t2 HAVING 1=2);
-- After
SELECT * FROM t1 WHERE false

Cela empêche totalement l'exécution de la sous-requête.

Vérification par l'exemple :

1. Préparez les données de test :

   DROP TABLE IF EXISTS t1;
   DROP TABLE IF EXISTS t2;
   CREATE TABLE t1 (id INT);
   CREATE TABLE t2 (val INT);
   INSERT INTO t1 VALUES (1), (2);

2. Examinez le plan d'exécution sans optimisation :

   SET simplify_subq_mode = 'OFF';
   EXPLAIN SELECT * FROM t1 WHERE EXISTS(SELECT MAX(a) FROM t2);
   SHOW WARNINGS;

   Résultat — la sous-requête EXISTS est évaluée au moment de l'exécution :

   /* select#1 */ select `testdb`.`t1`.`id` AS `id` from `testdb`.`t1` where exists(/* select#2 */ select max(`testdb`.`t1`.`id`) from `testdb`.`t2`)

3. Examinez le plan d'exécution avec l'optimisation activée :

   SET simplify_subq_mode = 'ON';
   EXPLAIN SELECT * FROM t1 WHERE EXISTS(SELECT MAX(a) FROM t2);
   SHOW WARNINGS;

   Résultat — la clause EXISTS a disparu :

   /* select#1 */ select `testdb`.`t1`.`id` AS `id` from `testdb`.`t1`

Scénario 3 : Ajouter LIMIT 1 aux projections constantes dans les sous-requêtes ANY/ALL

Cas d'application : La sous-requête située dans une clause ANY ou ALL sélectionne uniquement une constante (aucune référence de colonne). Récupérer plusieurs lignes identiques étant inefficace, l'optimiseur injecte LIMIT 1.

Modèle de réécriture :

-- Before
SELECT * FROM t1 WHERE a > ANY (SELECT 1 FROM t2);

-- After
SELECT * FROM t1 WHERE a > ANY (SELECT 1 FROM t2 LIMIT 1);

Cette technique évite un balayage complet de la table t2 lorsque le résultat constant est identique pour chaque ligne.