Points clés
- Catégorie
- Développement et Web
- Types d’entrée
- textarea, select, number
- Type de sortie
- html
- Couverture des échantillons
- 4
- API disponible
- Yes
Vue d’ensemble
Le Visualiseur de Plan d’Exécution SQL transforme vos sorties textuelles ou JSON brutes issues de commandes EXPLAIN (PostgreSQL, MySQL, SQLite) en un arbre de coûts interactif et coloré. Il identifie instantanément les goulots d'étranglement de vos requêtes, tels que les scans de table complets ou les écarts de statistiques, et vous propose des suggestions concrètes d'indexation ou de réécriture.
Quand l’utiliser
- •Lors de l'optimisation de requêtes SQL lentes s'exécutant sur PostgreSQL, MySQL ou SQLite.
- •Pour identifier les écarts importants entre les lignes estimées par le planificateur et les lignes réellement lues lors d'un EXPLAIN ANALYZE.
- •Pour détecter rapidement les scans séquentiels (Seq Scan) ou les tris sur disque (filesort) nécessitant la création d'index.
Comment ça marche
- •Collez la sortie brute de votre commande EXPLAIN ou EXPLAIN ANALYZE (au format JSON ou texte brut) dans le champ dédié.
- •Sélectionnez le dialecte de votre base de données (PostgreSQL, MySQL, SQLite) ou laissez l'outil le détecter automatiquement.
- •Ajustez éventuellement la profondeur maximale de l'arbre et ajoutez la requête SQL d'origine pour affiner le diagnostic.
- •Analysez l'arbre généré pour repérer les nœuds critiques colorés et appliquez les suggestions d'indexation recommandées.
Cas d’usage
Exemples
1. Résolution d'un Seq Scan sur PostgreSQL
Développeur Backend- Contexte
- Un développeur constate que la recherche d'utilisateurs par adresse e-mail prend plusieurs secondes en production.
- Problème
- Identifier pourquoi l'index sur la table `users` n'est pas utilisé lors de la recherche par e-mail.
- Comment l’utiliser
- Coller la sortie JSON de `EXPLAIN (FORMAT JSON, ANALYZE)` de la requête dans le visualiseur.
- Configuration d’exemple
-
{ "dialect": "postgresql", "sql": "SELECT * FROM users WHERE lower(email) = '[email protected]'" } - Résultat
- L'outil met en évidence un Seq Scan avec un écart de lignes (1000 estimées vs 95000 réelles) et suggère de créer un index fonctionnel sur `lower(email)`.
2. Optimisation d'un tri lourd sur MySQL
Administrateur de Base de Données- Contexte
- Une requête de tableau de bord trie les commandes par date de création sans limite de lignes, provoquant des ralentissements.
- Problème
- Visualiser l'impact du tri et valider la nécessité d'un index ou d'une réécriture de requête.
- Comment l’utiliser
- Coller la sortie textuelle tabulaire de `EXPLAIN` MySQL contenant les colonnes `type`, `key` et `Extra`.
- Configuration d’exemple
-
{ "dialect": "mysql", "sql": "SELECT * FROM orders ORDER BY created_at" } - Résultat
- L'arbre affiche un avertissement de type "filesort" et recommande d'ajouter un index sur la colonne `created_at` ou d'ajouter une clause `LIMIT`.
Tester avec des échantillons
json, sql, textHubs associés
FAQ
Quels moteurs de bases de données sont pris en charge ?
L'outil prend en charge PostgreSQL (JSON et texte), MySQL (JSON et tabulaire classique) et SQLite (EXPLAIN QUERY PLAN).
Comment l'outil détecte-t-il les problèmes de statistiques obsolètes ?
Il compare les lignes estimées et les lignes réelles de la sortie ANALYZE et signale tout écart supérieur ou égal à un facteur 10.
Faut-il obligatoirement fournir la requête SQL d'origine ?
Non, la requête SQL est optionnelle, l'analyse repose principalement sur la structure de la sortie EXPLAIN fournie.
Qu'est-ce qu'un prédicat non sargable détecté par l'outil ?
C'est une condition (comme une fonction appliquée sur une colonne) qui empêche le moteur de base de données d'utiliser efficacement un index existant.
Mes données de plan d'exécution sont-elles envoyées à un serveur tiers ?
Non, l'analyse et la visualisation de votre plan d'exécution SQL sont traitées localement dans votre navigateur pour garantir la confidentialité de vos données.