PolarDB:Adaptive execution plan switching

Fonctionnement

Ces deux modes reposent sur un mécanisme commun en trois phases :

1. Phase d'optimisation : l'optimiseur définit des seuils de nombre de lignes pour chaque bloc de requête ainsi que pour la requête globale, puis les intègre aux métadonnées de surveillance. S'il ne sélectionne pas IMCI ou s'il opte pour un index ordonné via prefer_ordering_index, il calcule le seuil déclenchant le basculement de plan.

2. Phase d'exécution : pendant l'exécution de la requête, la base de données comptabilise les lignes analysées dans le chemin critique au moyen de simples comparaisons d'entiers, sans engendrer de surcharge de performance. Dès que ce compteur atteint le seuil, le système évalue l'opportunité de basculer vers un plan alternatif.

3. Basculement de plan : avant toute transition, la base de données vérifie qu'aucun résultat partiel n'a été renvoyé au client. Elle efface ensuite les résultats intermédiaires mis en cache et poursuit le traitement selon le nouveau plan.

Pour les clusters exécutant la version 8.0.1.1.49 ou ultérieure (ou 8.0.2.2.29 ou ultérieure), le paramètre loose_adaptive_cost_threshold_for_imci régit le seuil du routage adaptatif ligne-colonne. Pour les versions antérieures, ce seuil dépend de loose_cost_threshold_for_imci.

Le diagramme suivant illustre le flux du routage adaptatif ligne-colonne.

Prérequis

Avant d'activer le basculement adaptatif des plans d'exécution, assurez-vous que votre cluster satisfait aux exigences de version correspondant au mode souhaité.

Routage adaptatif ligne-colonne (imci_chosen=on) :

• PolarDB for MySQL 8.0.1, version de révision 8.0.1.1.39 ou ultérieure

• PolarDB for MySQL 8.0.2, version de révision 8.0.2.2.29 ou ultérieure

Sélection adaptative des index ordonnés (ordering_index=on) :

• PolarDB for MySQL 8.0.1, version de révision 8.0.1.1.47 ou ultérieure

• PolarDB for MySQL 8.0.2, version de révision 8.0.2.2.29 ou ultérieure

Activer ou désactiver le basculement adaptatif des plans d'exécution

Connectez-vous à la console PolarDB et accédez à la page Parameters de votre cluster. Pour connaître la procédure de configuration, consultez Configurer les paramètres du cluster et des nœuds.

Définissez loose_adaptive_plans_switch sur l'une des valeurs suivantes :

• 'imci_chosen=on' — active le routage adaptatif ligne-colonne

• 'ordering_index=on' — active la sélection adaptative des index ordonnés

• 'imci_chosen=on,ordering_index=on' — active simultanément les deux modes

• Définissez l'une des sous-clés sur 'off' pour désactiver le mode correspondant

Le tableau ci-dessous détaille l'ensemble des paramètres configurables.

Limites des solutions par défaut

Avant l'introduction du basculement adaptatif des plans d'exécution, corriger un routage erroné ou une sélection d'index inadéquate imposait l'une des deux approches manuelles suivantes :

• Abaisser globalement le seuil de coût du stockage colonne : cette méthode achemine davantage de requêtes vers les nœuds de stockage colonne, mais dirige également des requêtes courtes et légères vers IMCI. Cela alourdit la charge de ces nœuds et risque de bloquer d'autres charges de travail.

• Recourir au statement outline pour figer des modèles de requêtes spécifiques : la fonctionnalité de statement outline permet de contraindre une requête donnée à utiliser le stockage colonne ou de désactiver prefer_ordering_index :

  -- Force a query to use column store
  CALL dbms_outln.add_optimizer_outline("<schema_name>", "/*+ SET_VAR(cost_threshold_for_imci=0) SET_VAR(imci_ap_threshold=0) */", "<query>");
  
  -- Disable prefer_ordering_index for a specific query template
  CALL dbms_outln.add_optimizer_outline("<schema_name>", "/*+ SET_VAR(optimizer_switch='prefer_ordering_index=off') */", "<query>");

  Bien que précise, cette approche engendre des coûts opérationnels importants, car chaque modèle de requête problématique doit être identifié et géré individuellement.

Le basculement adaptatif des plans d'exécution résout automatiquement ces deux problèmes : il ne change de plan que lorsque les données d'exécution confirment une erreur d'estimation de l'optimiseur, laissant ainsi intactes les requêtes correctement évaluées.

Choix de l'approche appropriée : privilégiez loose_adaptive_plans_switch (automatique) comme option par défaut, car elle ne nécessite aucune configuration par requête et s'adapte aux observations d'exécution. Réservez le statement outline (manuel) aux cas où un comportement déterministe est requis pour un modèle de requête précis, indépendamment des statistiques d'exécution.

Vérifier l'activité du basculement adaptatif

Exécutez l'instruction suivante pour consulter le nombre total de basculements adaptatifs effectués depuis l'activation de la fonctionnalité :

SHOW GLOBAL STATUS LIKE 'Adaptive_plan_used';

Étapes suivantes

• In-Memory Column Index (IMCI)

• Routage automatique ligne-colonne

• Statement outline

• Configurer les paramètres du cluster et des nœuds