Plans de requêtes SQL
Examinez le plan SQL avec des données représentatives.
EXPLAIN
SELECT id, title
FROM entries
WHERE category = 'example'
ORDER BY created_at;Projet
Comparez estimations et chemins d’accès et vérifiez le résultat avant d’attribuer un gain à un index.
Vérifiez avant d’appliquer
Comparez le comportement observé au résultat attendu. Si une vérification échoue, cherchez la cause avant de poursuivre les modifications.
Modèles
Configurez un endpoint compatible OpenAI ou Anthropic avec son URL de base et une clé API si nécessaire. Testez la connexion. Un serveur local doit fonctionner ; les outils distants peuvent transmettre des données séparément.
EXPLAIN
SELECT id, title
FROM entries
WHERE category = 'example'
ORDER BY created_at;Donnez un contexte applicatif aux modifications de base de données
Codepoint Studio intègre le développement lié aux bases de données à un espace de programmation avec IA pour Windows, où le dossier du projet ancre la conversation. Commencez par le comportement applicatif à corriger, comme une liste lente ou un jeu de résultats inattendu. Demandez au modèle connecté d’examiner la requête et ses appelants avant de discuter de modifications, pour tenir compte de ce que l’application consomme réellement.
L’exemple query.sql utilise EXPLAIN comme point de départ d’une investigation avant de modifier les index. Dans votre projet, vous pouvez réunir dans la même tâche un plan expurgé, le schéma pertinent et l’ordre attendu des résultats de la requête. C’est une démarche de développement illustrative, pas un optimiseur de base de données intégré. Toute proposition d’index ou de révision de requête doit encore être examinée selon la version de votre base, sa charge et votre procédure de changement.
Un modèle sans restrictions est une option s’il est proposé par votre point de terminaison compatible OpenAI ou Anthropic pris en charge. Vous fournissez les détails de connexion et les identifiants si nécessaire ; le comportement du modèle et l’accès aux outils dépendent de cette configuration. Utilisez le raisonnement de l’assistant pour expliciter les hypothèses, puis examinez le correctif et exécutez des contrôles dans un environnement de base de données approprié. La justesse des résultats, les effets de migration et le plan d’exécution mesuré répondent chacun à une question différente sur la pertinence de la modification pour votre application.
Avant de modifier une requête ou un index
Quel contexte de base de données joindre à une requête lente ?
Incluez une requête expurgée, les définitions de tables pertinentes, la version de la base et un plan d’exécution disponible. Décrivez le nombre de lignes et l’ordre attendus. Évitez de partager des identifiants de production ou de supposer que le modèle peut se connecter à la base simplement parce que la requête est visible.
Une requête plus courte peut-elle être plus lente ?
Oui. La longueur du texte n’établit pas le coût d’exécution. Comparez les plans et les mesures dans un environnement représentatif de votre charge, et vérifiez les lignes renvoyées. Considérez l’explication de l’assistant comme une hypothèse jusqu’à ce que ces contrôles l’étayent.
Faut-il appliquer directement un index suggéré ?
Examinez son effet sur les écritures, le stockage et les index existants selon votre procédure habituelle de base de données. L’exemple n’autorise pas une modification du schéma. Séparez proposition et exécution jusqu’à avoir vérifié le comportement applicatif et les conséquences opérationnelles.
Comment vérifier l’appelant après une réécriture de requête ?
Confirmez les noms de champs, les valeurs manquantes, l’ordre et les attentes de pagination. Exécutez les tests applicatifs pertinents avec des données représentatives. Une instruction SQL valide peut néanmoins modifier un contrat dont dépend l’écran ou le service consommant son résultat.
Codepoint Studio · Mis à jour 2026-10-25
