按表结构与查询需求生成 MySQL 查询，并解释执行逻辑。
编程 · 由 周野 维护（CPCX 撰稿人 · 编程与数据）
请根据需求写 SQL（MySQL 8）：表结构如下，需求是{{查询需求}}，并解释执行逻辑。
表结构：
表结构带上字段类型和索引信息，生成的 SQL 才靠谱——没有索引信息，AI 可能写出一个在百万级表上全表扫描的查询。数据量级也要一并说明，千级和亿级数据的优化思路完全不同。
复杂查询建议两步走：先让 AI 讲清思路和表的关联顺序，确认理解一致后，再让它写完整 SQL。理解错了还往前走，后面只会越改越乱。
至少给出三样：涉及的表与字段、字段类型、表之间的关联键。索引信息也很有用——AI 知道走哪个索引，写出的查询才不至于全表扫描。如果表结构不方便贴，用文字描述也行：「orders 表有 user_id、amount、created_at，user_id 上有索引」。
需求描述里带上数据量级（「orders 大概 2000 万行」），它会更倾向于写带条件的查询而不是全表聚合。
需求可以这样写：「按月统计每个用户的有效订单金额，只算状态为 paid 且金额大于 0 的，最近 12 个月，按金额降序。」配合表结构，输出会包含按月的分组、状态过滤和排序。拿到 SQL 后先做两件事：`EXPLAIN` 看执行计划，再从结果里抽查一两个用户手工核对。
输入应该是「表结构 + 需求 + 口径」三件套。举例：orders 表有 id、user_id、amount、status、created_at，需求是「统计 2026 年 8 月各城市的付费用户数和客单价，按客单价降序」。同时说清口径——status = 2 表示已支付、客单价按「已支付订单总金额 / 付费用户数」计算、城市取自用户表。
这样的输入拿到的 SQL 通常是带 JOIN 的分组聚合，还会顺带提醒两件事：金额字段如果是分为单位要先除以 100；某城市一个付费用户都没有时，用它做分母会产生除零，需要用 NULLIF 兜一下。这两条提醒就是它比「只给需求」的写法多出来的价值。
先看执行计划，再拿小范围数据试跑。执行计划能告诉你有没有走索引、有没有全表扫描；小范围试跑能验证口径对不对。
很多人忽略的是「结果是否符合直觉」：客单价算出几千块、付费用户数比总用户数还多，这类明显不合理的数字，几乎都是口径或 JOIN 写反了导致的，跑之前先想一遍预期量级。
排查数据问题时，把「写 SQL」改成「帮我写几条用于核对的查询：先看总行数、再看关键字段的空值分布、最后列出异常记录」，用检查清单的思路代替单条查询，定位口径问题特别快。
做定期报表时，加一句「改成可以按日期参数化的写法，并说明时间范围应该怎么传」，输出会给出带占位参数的版本，方便你接进定时任务。
适合表结构清楚、需求能用一句话说清的查询：把表结构一起给它，出来的 SQL 通常能直接跑。
也适合你不熟 SQL、但需要取数的情况。