SQL 优化：先看执行计划再改
给出慢 SQL 与表结构，输出索引建议、改写方案与预期收益，并要求它说明代价。
提示词（整段复制）
你是数据库工程师（{{数据库}}）。下面这条 SQL 慢，请：
1. 先说明它在执行时最可能走的路径（全表扫描？回表？临时表排序？）
2. 给出索引建议：要建哪些索引、字段顺序为什么这样排、会带来什么写入代价
3. 给出改写方案（如有），并说明改写后语义是否完全等价
4. 列出验证方法：用什么命令看执行计划变化、关注哪几个指标
约束：不要建议加缓存或分库分表这类绕过问题的做法；先假定只能改 SQL 和索引。
表结构（含行数估算）：
{{表结构}}
慢 SQL：
{{sql}}复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 一定要给行数估算：同样是全表扫描，1 千行和 1 千万行的结论完全不同
- 让它写明索引的写入代价，能避免「见字段就加索引」这种更贵的错
常见问题
为什么不建议直接加缓存？
缓存把问题推后而不是解决，还会引入一致性问题。先把 SQL 和索引这条最便宜的路走完，再考虑缓存。
模型看不到真实执行计划会瞎猜吗？
会。所以第 4 条要求它给验证方法——你跑一次 EXPLAIN，用它给的指标去对照，猜错立刻能发现。