SQL query generation
Parle naturel, l'IA écrit du SQL
Les pièges de l'écriture SQL
Trois tableaux à JOIN, ton query sort 10× plus de lignes — quel JOIN c'est cassé ? Une demi-heure à debugger avant d'voir que tu as pas géré les relations many-to-many.
Sous-requête imbriquée trois niveaux, tu comprends plus ton propre code. Collègue demande "c'est quoi ce SQL", tu trouves pas les mots.
Pire c'est la perf : une query prend 30 sec, EXPLAIN tu lis et comprend rien. Tu ajoutes un index et ça ralentit encore ? Où c'est le truc ?
Tu dis en clair "query me les ventes totales par user dernier 30 jours, classe par montant haut à bas", boom SQL générée.
C'est plus qu'une traduction : ça considère les relations, volume data, index existant, SQL générée c'est correcte ET performante.
Query lente ? Balance SQL et EXPLAIN, il dit le goulet, l'index à ajouter, comment réécrire plus vite.Genre avoir un DBA assis à côté qui répond toujours.
3 Prompts SQL, couvre 90% des situations quotidiennes
Daily extractions jusqu'à optimisation perf, use quand tu besoin.
BDD a les tables :
- users(id, name, email, channel, created_at, status)
- user_profiles(user_id, age, gender, city)
Écris une SQL :
1. Nouveau users dernier 30j par jour
2. Groupe par canal (channel)
3. Stats retention jour 1 par canal aussi
4. Résultat sort date décroissant
DB : MySQL 8.0, users table ~5M rows.
Give les index qu'on devrait avoir.Cette query prend 30 sec, help optimize :
[Colle ta slow SQL]
EXPLAIN résultat :
[Colle EXPLAIN output]
Analyze :
1. Goulet ? (full scan? temp table? file sort?)
2. Quels index ajouter ? (CREATE INDEX statements)
3. Réécrire SQL plus vite ? (équivalent plus efficient)
4. Estime perf après optimisation ?
DB: PostgreSQL 15, tables ~20M rows.BDD a :
- users(id, name, registered_at)
- orders(id, user_id, product_id, amount, created_at, status)
- products(id, name, category, brand)
Ecris query :
1. Total dépense par user (juste completed orders)
2. Catégorie top purchase par user (tie = first)
3. Date première et dernière purchase par user
4. Juste users avec purchase année dernière
5. Top 100 par total dépense
DB: MySQL 8.0. Utilise CTE lisibilité.Config connection DB
Config optionnel pour laisser OpenClaw direct queryer ta DB et valider les résultats.
# Connexion DB (optionnel, après config l'IA peut queryer et valider)
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # STRONG: utilise readonly account!
password_env: DB_PASSWORD # env var, pas plaintext
# Limiteurs sécurité
read_only: true # juste SELECT, pas modif data
max_rows: 10000 # rows max par query
timeout: 30 # timeout query (sec)
# Pas besoin de config DB non plus, IA écrit SQL basée sur ton description
# Juste pas capable de tester la query aprèsSQL Gen : OpenClaw vs ChatGPT
Tous deux font SQL, mais différences.
- Lit ton DB schema, SQL match la structure réelle
- Direct connect DB et valide résultats (avec readonly account)
- Contexte : queries précédent, relations tables, tout tracked, ask pas repeat
- Local run, schema et logic métier leaks pas
- Juste basé ta description table structure, pas mal de supposition
- Pas run SQL direct, syntax correct tu vérifies toi
- Context window limité, complexe logic graduel il oublie
- SQL syntax ok mais logic wrong parfois, hard à debugger