Profileur et liste des processus

Deux outils pour la question « pourquoi est-ce lent ? » — l’un examine une requête, l’autre le serveur.

Profileur de requêtes

Cliquez sur Profileur dans la barre d’outils, ou sur le bouton Expliquer de l’éditeur SQL pour y envoyer directement l’instruction sur laquelle vous travaillez. Vous pouvez aussi choisir la connexion et la base et y coller une requête.

Le plan s’affiche sous forme de graphe : une boîte par opération, reliée aux entrées dont elle se nourrit, de sorte qu’une jointure se lit comme un nœud alimenté par deux tables plutôt que comme une indentation. Chaque boîte indique la table, la méthode d’accès, le nombre de lignes et le coût, avec une bande colorée qui la pondère par rapport au nœud le plus coûteux du plan. Cliquez sur une boîte pour le détail complet — conditions, noms d’index, compteurs de buffers.

Le même plan est disponible sous forme d’arbre, et dans la sortie brute du serveur.

Estimé ou mesuré

Un badge au-dessus du plan indique ce que vous regardez :

• Estimé — la supposition du planificateur. Rien n’a été exécuté.
• Mesuré — la requête a réellement été exécutée, et les boîtes affichent le nombre réel de lignes à côté des estimations.

Cochez ANALYZE pour demander un plan mesuré. La possibilité d’en obtenir un dépend du serveur, et NabuSQL indique ce qu’il a obtenu au lieu de se rabattre discrètement :

Moteur	Plans mesurés
MySQL 8.3+	Oui, avec le graphe complet
MariaDB 10.1+	Oui, avec le graphe complet
MySQL 8.0.18+	Oui, mais le serveur ne renvoie que du texte — pas de graphe
MySQL / MariaDB plus anciens	Non — vous obtenez l’estimation, indiquée comme telle
PostgreSQL	Oui, avec les compteurs de buffers
SQLite	Aucun plan d’exécution réel n’existe

SQL Server

SQL Server renvoie un plan estimé sous forme de tableau plutôt que de graphe. Lire son plan réel nécessite SHOWPLAN_XML, que NabuSQL n’analyse pas encore — la page le dit au lieu de faire semblant.

Lire un plan

Les nœuds qui méritent un second regard sont signalés par ⚠ :

• Parcours complet de la table — toute la table est lue là où vous attendiez une recherche par index.
• Faible sélectivité — un index a été utilisé mais n’a presque rien restreint.
• Estimation très éloignée — le planificateur attendait un nombre de lignes différent d’un ordre de grandeur. Généralement des statistiques obsolètes, et la raison de la forme du plan qu’il a choisie. Exécutez ANALYZE sur la table et réessayez.

À surveiller également : un coût concentré dans un seul nœud — c’est là qu’il faut optimiser en premier — et un index qui existe mais n’est pas utilisé, généralement parce que la clause WHERE enveloppe la colonne dans une fonction ou la compare à un autre type.

Après avoir ajouté un index dans Tables et colonnes, relancez le profileur et vérifiez que le plan a réellement changé. Un index que le planificateur ignore vous coûte des écritures et ne rapporte rien.

Liste des processus

Faites un clic droit sur une base et choisissez Liste des processus pour voir ce que fait le serveur en ce moment : les sessions connectées, les requêtes qu’elles exécutent et depuis combien de temps.

Arrêter termine une session. C’est l’outil pour une requête incontrôlée qui détient des verrous que le reste de l’application attend.

Arrêter une session l’annule

Une transaction interrompue est annulée par le serveur, ce qui, pour une écriture de longue durée, peut prendre autant de temps que l’instruction elle-même. Vérifiez ce que fait la session avant de l’arrêter.

Un ordre pratique

1. L’application est lente → Liste des processus : une requête bloque-t-elle tout ?
2. Une requête précise est lente → Profileur : où se situe son coût ?
3. Corrigez — index, WHERE réécrit, ordre de jointure différent.
4. Relancez le profileur et vérifiez que le plan a changé.