tablestudioapp/plugins

Accélérer les requêtes avec TableStudio

TableStudio mesure, ne se contente pas de deviner. Ne recommandez jamais un index ou une réécriture par intuition alors que vous pouvez le prouver avec les outils ci-dessous. La plupart d'entre eux sont réservés à PostgreSQL ; sur d'autres moteurs, utilisez explain_query et raisonnez à partir du plan.

Choisissez d'abord la connexion, comme décrit dans la compétence database-workflow. Privilégiez l'analyse sur une base de données avec des données réalistes. Une base de développement presque vide donne des plans trompeurs.

Trouver ce qui est lent

• L'utilisateur nomme une requête ou un endpoint : trouvez le SQL qu'elle exécute (à partir du code ou des journaux ORM), puis allez dans "Diagnostiquer une instruction".
• "Pourquoi la base de données est-elle lente ?" Appelez slow_queries. Il classe les instructions par temps total à partir de pg_stat_statements. Conservez le query_id de chaque ligne ; les autres outils l'acceptent. Si l'extension n'est pas installée, l'outil explique ce qu'implique son activation, transmettez ces informations plutôt que de l'installer sans demander.
• Réglage général : workload_index_advisor trouve le moins d'index qui couvrent le plus de temps de base de données et liste les index existants qui ne sont jamais utilisés.

Un bilan de santé

Lorsque l'utilisateur demande ce qui ne va pas avec une base de données, ou souhaite une revue générale, ne modifiez rien et rapportez :

1. database_health. Lisez sa liste unavailable avant de résumer : une liste de constats vide avec des entrées ici signifie que les vérifications ont été ignorées, pas que tout va bien.
2. database_overview pour la taille, les tables les plus grandes et les plus actives, et le nombre de connexions.
3. schema_issues (sans table) pour les problèmes de conception sur l'ensemble de la base de données.

Placez les constats les plus importants en premier, en langage clair : ce qui ne va pas, son coût si ignoré, et le correctif. Incluez le verify_sql de chaque constat pour que l'utilisateur puisse vérifier le nombre, et tout lock_impact du correctif. Proposez de mettre en œuvre les correctifs choisis par l'utilisateur via "Mettre en production" ci-dessous.

Diagnostiquer une instruction

1. optimize_query avec le SQL (et query_id s'il provient de slow_queries). Pour une instruction en lecture seule, passez analyze: true afin que les vérifications mesurées puissent s'exécuter. Il s'exécute une fois dans une transaction annulée. Il signale already_fast lorsqu'il n'y a rien à faire ; dites-le plutôt que d'inventer une amélioration.
2. Pour plus de détails, utilisez explain_query (analyze: true pour les lectures uniquement). Comparez actual_rows avec estimated_rows sur chaque nœud. Un écart important signifie des statistiques obsolètes (lancez ANALYZE sur la table), ce qui est souvent le véritable bogue plutôt qu'un index manquant.
3. Une instruction avec des paramètres $1, $2 a besoin de vraies valeurs pour planifier honnêtement. suggest_parameter_values les trouve à partir de l'historique, des sessions actives et des statistiques.

Prouver le correctif

Utilisez benchmark_query_variants (le Laboratoire de requêtes) avant de recommander quoi que ce soit :

• Donnez-lui le SQL de référence et les candidats comme variants : un sql réécrit, des hypothetical_indexes (planifiés avec hypopg, jamais construits), hide_indexes, ou des paramètres settings du planificateur. Ou omettez variants et laissez find_faster proposer les siens.
• Il rapporte les médianes sur plusieurs exécutions pour chaque ensemble de paramètres et vérifie que chaque réécriture retourne les mêmes lignes que la référence.
• Ne recommandez qu'une variante dont same_rows est oui. Préférez la variante dans recommendation. Citez les mesures avant et après, pas des pourcentages issus de l'intuition.

Avant de supprimer un index (inutilisé ou en double), exécutez index_what_if avec celui-ci dans hide. Toute instruction qui devient plus coûteuse, ou qui utilise l'index aujourd'hui, serait impactée.

Mettre en production

Les index et les réécritures passent par le flux de changement normal de la compétence database-workflow :

• Les modifications d'index sont des modifications de schéma. Si le dépôt a un outil de migration, ajoutez l'index là. Sinon, proposez-le avec stage_migration, avec les mesures chiffrées dans rationale.
• Sur PostgreSQL, utilisez CREATE INDEX CONCURRENTLY pour toute table qui voit du trafic, et ne l'enveloppez pas dans une transaction.
• Une réécriture de requête est une modification de code : modifiez le code qui l'émet et mentionnez le résultat du benchmark dans votre résumé.