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 多张表的时候，万一笛卡尔积了，数据库可能直接挂掉。