SQL 查詢生成
用人話描述需求，AI 幫你寫 SQL
寫 SQL 的那些坑
JOIN 寫不對、子查詢套到頭暈
三張表 JOIN，寫完跑出來的數據行數比預期多了 10 倍──哪個 JOIN 寫錯了？排查半小時才發現是多對多關係沒處理好。
子查詢嵌套三層，自己寫完自己都看不懂了。同事過來問「這條 SQL 是幹嘛的」，你看了兩分鐘說「等我想想」。
更崩潰的是性能問題：一條查詢跑了 30 秒，EXPLAIN 看了半天也看不出哪裡有問題。加了索引反而更慢了？到底是哪裡不對？
OpenClaw：理解業務邏輯，寫出靠譜的 SQL
你用大白話說「查出每個用戶最近 30 天的消費總額，按金額從高到低排」，OpenClaw 直接給你生成規範的 SQL。
不只是簡單翻譯：它會考慮表之間的關聯關係、數據量級、索引情況，生成的 SQL 不但正確，而且性能不差。
遇到慢查詢？把 SQL 和 EXPLAIN 結果一起丟給它，它會告訴你瓶頸在哪、該加什麼索引、怎麼改寫更快。相當於身邊坐了個 DBA 隨時答疑。
3 條 SQL Prompt，覆蓋日常 90% 場景
從日常取數到性能優化，按需使用。
日常取數：最近 30 天新增用戶按渠道分組
黃金指令
數據庫裡有以下表：
- users（id, name, email, channel, created_at, status）
- user_profiles（user_id, age, gender, city）
幫我寫一條 SQL：
1. 查出最近 30 天每天的新增用戶數
2. 按註冊渠道（channel）分組
3. 同時統計每個渠道的次日留存率
4. 結果按日期倒序排列
數據庫是 MySQL 8.0，users 表大約 500 萬行。
請同時給出建議的索引。日常取數最常見的模式。記得告訴 AI 你用的數據庫類型和數據量級，不同數據庫的語法有差異（比如日期函數），數據量級影響查詢策略。
慢查詢優化：30 秒的 SQL 怎麼救
進階技巧
這條 SQL 跑了 30 秒，幫我優化：
[在這裡貼上你的慢 SQL]
EXPLAIN 結果：
[在這裡貼上 EXPLAIN 輸出]
請分析：
1. 瓶頸在哪裡（全表掃描？臨時表？檔案排序？）
2. 需要加哪些索引（給出 CREATE INDEX 語句）
3. SQL 怎麼改寫能更快（有沒有等價但更高效的寫法）
4. 預估優化後的執行時間
數據庫：PostgreSQL 15，表數據量約 2000 萬行。優化慢查詢一定要帶上 EXPLAIN 結果，光看 SQL 很難判斷真正的瓶頸。也別忘了說數據量──100 行和 2000 萬行的優化策略完全不一樣。
複雜業務查詢：用戶消費分析
黃金指令
數據庫裡有三張表：
- users（id, name, registered_at）
- orders（id, user_id, product_id, amount, created_at, status）
- products（id, name, category, brand）
幫我寫一個查詢：
1. 每個用戶的總消費金額（只算已完成的訂單）
2. 每個用戶購買次數最多的品類（如果並列取第一個）
3. 每個用戶的首次和末次購買時間
4. 只看最近一年有過消費的用戶
5. 按總消費金額從高到低排序，取 Top 100
數據庫：MySQL 8.0。請用 CTE 讓 SQL 可讀性好一些。多表關聯 + 聚合 + 排名，這種查詢手寫很容易出錯。讓 AI 用 CTE 來寫，可讀性好很多，後面改需求也方便。
數據庫連接配置
讓 OpenClaw 直接連庫查數據的配置（可選，不配置也能生成 SQL）。
數據庫連接配置（.openclaw.yml）
# 數據庫連接（可選，配了之後 AI 能直接查數據驗證結果）
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # 強烈建議用只讀帳號！
password_env: DB_PASSWORD # 從環境變數讀密碼，別明文寫
# 安全限制
read_only: true # 只允許 SELECT，禁止修改數據
max_rows: 10000 # 單次查詢最多返回行數
timeout: 30 # 查詢超時（秒）
# 不配數據庫也沒關係，AI 照樣能根據你描述的表結構生成 SQL
# 只是沒法幫你直接跑一遍驗證結果而已
連接生產數據庫時，務必使用只讀帳號。雖然 OpenClaw 有安全限制，但安全這事寧可多一層保險。建議連只讀副本，別連主庫。
寫 SQL：OpenClaw vs ChatGPT
都能生成 SQL，但細節差別不小。
OpenClaw
- 能讀取你的數據庫 schema，生成的 SQL 跟實際表結構完全匹配
- 可以直連數據庫驗證查詢結果（配置只讀帳號後）
- 理解上下文：之前的查詢、表關係都記著，追問不用重複說
- 本地執行，你的表結構和業務邏輯不會外洩
VS
ChatGPT
- 只能根據你描述的表結構生成 SQL，猜的成分比較多
- 沒法直接跑 SQL 驗證，語法對不對得自己去試
- 上下文視窗有限，複雜業務邏輯聊著聊著就忘了
- 生成的 SQL 有時候語法對但邏輯錯，不好排查
真實場景
數據分析師：老闆臨時加需求
下午三點，老闆突然發消息：「幫我查一下最近三個月各渠道的 ROI，按週統計，五點前要。」你對這幾張表的關聯關係不太熟，手寫 SQL 沒把握。
OpenClaw 方案
把表結構告訴 OpenClaw，用大白話說需求，兩分鐘拿到 SQL。直連數據庫跑一遍，結果沒問題，順便讓 AI 解釋一下每段 SQL 的邏輯，自己也學到了。四點就交了，還提前。
自己硬寫
先翻文件看表結構，再寫 SQL，JOIN 寫錯了跑出來數據不對，排查了一小時。好不容易改對了，又發現日期函數用錯了。五點交不出來，跟老闆說「再給我半小時」。
SQL 生成小技巧
讓 AI 生成 SQL 時，務必告訴它：數據庫類型（MySQL / PostgreSQL / SQLite）、表的大致數據量、已有的索引。這三個信息直接影響生成的 SQL 品質。
複雜查詢讓 AI 用 CTE（WITH 子句）來寫，別用嵌套子查詢。CTE 可讀性好太多，改需求的時候不用從裡到外一層層扒。
養成好習慣：讓 AI 生成 SQL 後，先加 LIMIT 100 跑一遍看看結果對不對，別直接在大表上跑全量查詢。尤其是 JOIN 多張表的時候，萬一笛卡爾積了，數據庫可能直接掛掉。