为什么需要分层的 SQL Skill 工作流
- SQL 工作通常包含：确认方言与表结构、草拟查询、评估执行计划与性能、以及在需要时制定迁移或索引方案。
- 把这些步骤用 Skill 分层（查询类、性能类、建模类）能提高复用性并降低直接在生产库执行错误语句的风险。
- 本教程演示如何在只读/测试边界内进行可验证的迭代：先产出 SQL -> 用 EXPLAIN/慢日志对比 -> 制定可回滚的 DDL/迁移计划。
如何按任务选择 Skill 类型（概念性指南）
- 查询与报表（当表结构稳定、目标是指标或报表）
- 适合任务：复杂 JOIN、聚合、窗口函数、业务分组/口径校验。 - 期待输出：可执行的 SELECT、样例结果集说明、必要时图表或报表结构说明。
- 慢查询与索引优化（当已出现性能问题）
- 适合任务：有 EXPLAIN、慢查询日志或可测基准的场景。 - 期待输出：执行计划分析、重写建议、候选索引（含风险与成本估计）。
- 表结构与迁移（新建或结构变更）
- 适合任务：设计 ER 图、定义约束与索引、编写可回滚迁移脚本与回填策略。 - 期待输出：表定义（DDL）、索引方案、分批迁移与回滚步骤说明。
提示：始终在测试环境或只读账户上先验证 SQL/EXPLAIN；不要把未验证的 DDL 直接运到生产库。
一个完整的工作流示例（问题场景与目标）
场景：报表查询在高流量时段变慢。目标：在测试库上找出慢点，验证一个重写（减少行数、用合适索引）并准备可回滚的索引变更方案。
示例数据集（用于描述给 Skill 的最小输入）
- 引擎：MySQL 8.x（在说明中指明方言与版本）
- 表 users(id PK, created_at DATETIME, region VARCHAR), orders(id PK, user_id FK, amount DECIMAL, status, created_at)
- 现有索引：users PK(id); orders PK(id), idx_orders_user_created (user_id, created_at)
- 慢查询：每小时按 region 汇总付费用户数与消费总额的报表，在高并发时超过响应 SLA。
- 原始 SQL（示例）：
SELECT u.region, COUNT(DISTINCT o.user_id) AS pay_users, SUM(o.amount) AS total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' AND o.created_at >= '2026-11-01' AND o.created_at < '2026-12-01' GROUP BY u.region;
目标输出：1) 当前 EXPLAIN；2) 一个低成本的重写 OR 索引建议；3) 可回滚索引变更步骤与验证检查点。
具体步骤（可复制给 Skill/Agent 的输入流程）
1) 固定输入范围与权限 - 明确只读或测试库；提供表结构（含主键、现有索引、行数估计）与原始 SQL、时间窗口样本。 2) 获取基线计划与运行数据 - 在测试库运行 EXPLAIN (或 EXPLAIN ANALYZE 如受支持) 并保存输出；记录执行时长与返回行数样例。 3) 分析执行计划（按项检查） - 检查是否存在全表扫描、错误的索引选择或大量临时表/文件排序；评估 JOIN 顺序与行估计误差。 4) 形成替代方案 - 优先尝试按查询重写：减少扫描行（把时间过滤尽量早地应用）、避免不必要的 DISTINCT、改用子查询或预聚合等。 - 如果索引更合适，列出候选索引（精确列顺序、是否覆盖查询、估计写放大与存储成本）。 5) 验证替代方案 - 在相同测试数据上比较原始与重写的 EXPLAIN 与实际耗时，记录差异。 6) 如果要在生产添加索引，准备迁移脚本 - 包含：创建索引的非阻塞/在线方法（若数据库支持）、备份策略、分批创建或时间窗、回滚命令（DROP INDEX）、监控指标（耗时、锁等待、错误率）。 7) 复盘与文档 - 保存原 SQL、所有 EXPLAIN 输出、耗时对比表、以及迁移风险评估与验收标准。
示例中的具体建议（基于示例数据）
- 常见重写：把时间过滤应用到 orders 表的扫描起点，或先对 orders 按 user_id 做聚合（按 user_id 计是否有 paid），再与 users 做 JOIN 来避免 COUNT(DISTINCT)。
- 候选索引示例（说明列顺序与目的）：
- 索引 A: (status, created_at, user_id) —— 目标：先过滤 status，再按时间定位，再用于聚合/连接。 - 索引 B: (created_at, status, user_id) —— 若查询常以时间为主过滤，可把时间列放前。 （注意：实际选择需基于数据分布与现有写负载评估。）
验证检查清单（在每步必须做的核对）
- 输入校验：确认表结构、主键与现有索引是否准确；核对字段含义（比如 status 值集合）。
- 语义校验：用手工样本行计算期望结果，核对重写后的结果是否一致。
- 性能对比：对比 EXPLAIN（估算成本）与真实耗时，注意缓存或并发带来的差异，重复测试以减小偶发性误差。
- 迁移风险：评估索引创建对写入延迟的影响；如需回填，估算窗口与监控指标（错误率、锁等待）。
常见限制与风险说明
- 不要假定所有建议都能在线安全执行：某些索引创建或 DDL 可能会锁表或导致回填操作耗时很长。必须包含回滚与窗口策略。
- 自动生成的 SQL 可能语法正确但语义不符：例如 join 粒度、NULL 处理、时区或去重逻辑常导致业务口径错误。务必用样本验证。
- EXPLAIN 的输出依赖数据库版本与配置；不同引擎/版本的计划格式与含义不同，建议在相同版本的测试环境中运行对比。
小结：把可验证性放在第一位
- 按“提出问题 -> 提供最小可验证输入 -> 产出 SQL/计划 -> 在测试环境验证 -> 再部署”这个迭代流程进行。
- 为每一次变更保留证据：原始 SQL、EXPLAIN、耗时与结果样本。任何写入或 DDL 都应有明确的回滚方案与人工审批。
（结束）