Compétences sql-optimization-patterns
📦

sql-optimization-patterns

Sûr

Optimiser les requêtes SQL et les performances de la base de données

Également disponible depuis: wshobson

Les requêtes de base de données lentes frustrent les utilisateurs et augmentent les coûts d'infrastructure. Cette compétence fournit des modèles systématiques pour analyser les plans de requête, concevoir des index efficaces et transformer les requêtes SQL lentes en opérations haute performance.

Prend en charge: Claude Codex Code(CC)
🥉 74 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "sql-optimization-patterns". Query with sequential scans on a 10M row table

Résultat attendu:

Analyse : L'EXPLAIN montre un Sequential Scan car aucun index n'existe sur la colonne 'created_at' utilisée dans la clause WHERE. Recommandation : CREATE INDEX idx_orders_created ON orders(created_at DESC). Amélioration attendue : Le temps de requête devrait passer de 2,3s à moins de 50ms pour les plages de dates récentes.

Utilisation de "sql-optimization-patterns". N+1 pattern loading user orders individually

Résultat attendu:

Problème : 101 requêtes exécutées (1 pour les utilisateurs + 100 pour les commandes). Solution : Remplacer par une seule requête JOIN ou utiliser le chargement par lot avec WHERE user_id IN (...). L'approche refactorisée réduit les allers-retours base de données de 99% et le temps d'exécution total de 5,2s à 120ms.

Audit de sécurité

Sûr
v1 • 2/25/2026

Static analysis flagged 103 potential issues that are all false positives. The 'external_commands' findings are markdown code fence backticks in documentation, not shell execution. The 'weak cryptographic algorithm' findings reference SQL examples, not actual crypto code. The 'filesystem' finding is a PostgreSQL COPY command syntax example in documentation. This skill contains only markdown documentation with SQL optimization patterns and examples - no executable code or security risks.

2
Fichiers analysés
543
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Optimisation de la plateforme e-commerce

Une équipe de développement rencontre des problèmes avec la recherche de produits lente et les requêtes d'historique des commandes pendant les pics de trafic. La compétence les aide à analyser les journaux de requêtes lentes, identifier les index manquants sur les colonnes fréquemment filtrées et refactoriser les modèles N+1 dans le chargement des commandes pour réduire les temps de réponse API de secondes à millisecondes.

Performances du tableau de bord analytique

Un ingénieur des données doit accélérer les requêtes d'agrégation pour les tableaux de bord en temps réel affichant les métriques de ventes. La compétence guide l'implémentation de vues matérialisées pour les calculs coûteux, des index de couverture pour les scans d'index uniquement et des modèles GROUP BY efficaces pour atteindre des temps de rafraîchissement de tableau de bord inférieurs à la seconde.

Modernisation des applications héritées

Un développeur héritier d'une application avec des dizaines de requêtes lentes causant des erreurs de timeout. La compétence fournit une approche systématique : capturer les requêtes lentes avec pg_stat_statements, analyser les plans d'exécution, hiérarchiser les optimisations à fort impact et implémenter une indexation appropriée pour éliminer 90% des problèmes de performance sans réécriture de l'application.

Essayez ces prompts

Analyse de requête basique 
I have a slow SQL query that takes over 5 seconds to run. Here is the query and table structure: [paste query and schema]. Can you analyze what might be causing the slowness and suggest specific indexes to create?
Interprétation du plan EXPLAIN 
I ran EXPLAIN ANALYZE on my query and got this output: [paste EXPLAIN output]. Please explain what each operation means, identify the performance bottlenecks, and recommend specific optimizations.
Conception de la stratégie d'indexation 
I have a table with columns [list columns] and my most common queries are: [list queries]. What indexing strategy should I use? Consider composite indexes, partial indexes, and covering indexes where appropriate.
Refactorisation des requêtes N+1 
My application executes hundreds of similar queries in a loop: [describe pattern or show code]. This is causing performance issues. Help me refactor this using JOINs, batch loading, or other techniques to reduce the number of database round-trips.

Bonnes pratiques

  • Utilisez toujours EXPLAIN ANALYZE pour comprendre l'exécution réelle de la requête avant d'optimiser
  • Créez des index sur les colonnes utilisées dans les clauses WHERE, JOIN et ORDER BY - mais évitez la sur-indexation car chaque index ralentit les opérations d'écriture
  • Récupérez uniquement les colonnes requises au lieu de SELECT *, et filtrez les données le plus tôt possible dans la requête

Éviter

  • Utiliser des fonctions sur des colonnes indexées dans les clauses WHERE sans index fonctionnels correspondants
  • La pagination avec de grandes valeurs OFFSET sur les grandes tables au lieu d'approches basées sur les curseurs
  • Exécuter des requêtes dans des boucles applicatives (modèle N+1) au lieu du chargement par lot ou des JOINs

Foire aux questions

Comment identifier quelles requêtes optimiser en premier ?
Concentrez-vous sur les requêtes à fort impact total : les requêtes fréquentes avec une lenteur modérée comptent souvent plus que les requêtes rares très lentes. Utilisez pg_stat_statements (PostgreSQL) ou les journaux de requêtes lentes pour trouver les requêtes par temps d'exécution total et nombre d'appels.
L'ajout de plus d'index améliorera-t-il toujours les performances ?
Non. Les index accélèrent les lectures mais ralentissent les opérations INSERT, UPDATE et DELETE. Chaque index consomme de l'espace de stockage et doit être maintenu. Concentrez-vous sur les index qui supportent vos requêtes les plus critiques et évitez d'indexer les colonnes à faible cardinalité.
Quelle est la différence entre EXPLAIN et EXPLAIN ANALYZE ?
EXPLAIN montre le plan de requête estimé basé sur les statistiques des tables. EXPLAIN ANALYZE exécute réellement la requête et rapporte les temps réels et les nombres de lignes, révélant les écarts entre les estimations et la réalité qui indiquent souvent des statistiques obsolètes ou des problèmes de parameter sniffing.
Quand dois-je utiliser un index composite plutôt que des index séparés ?
Utilisez des index composites lorsque les requêtes filtrent sur plusieurs colonnes ensemble. Ordonnez les colonnes par sélectivité (la plus sélective en premier) et prenez en compte vos modèles de requêtes. Un index composite sur (A, B) supporte les requêtes filtrant sur A seul ou A+B ensemble, mais pas sur B seul.
Comment savoir si mon index est utilisé ?
Interrogez pg_stat_user_indexes (PostgreSQL) pour vérifier les comptages idx_scan. Si un index montre zéro ou très peu de scans malgré des requêtes pertinentes, il peut ne pas être utilisable ou l'optimiseur a choisi un plan différent. Utilisez EXPLAIN pour vérifier l'utilisation de l'index pour des requêtes spécifiques.
Qu'est-ce que la pagination basée sur les curseurs et quand dois-je l'utiliser ?
La pagination basée sur les curseurs utilise une clause WHERE avec la dernière valeur vue (par exemple, WHERE created_at < last_cursor) au lieu de OFFSET. Elle maintient des performances constantes quelle que soit la profondeur de la page, contrairement à OFFSET qui doit scanner et ignorer toutes les lignes précédentes.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/sql-optimization-patterns

Réf

main

Structure de fichiers

📁 resources/

📄 implementation-playbook.md

📄 SKILL.md