SQL 优化模式
将以下提示词粘贴到你的 AI 对话框中：
请根据 https://skillhub.cn/install/skillhub.md，安装 @org-02qudk26/sql-optimization-patterns-zh。
技能介绍
慢查询从哪下手
应用变慢、数据库 CPU 飙高、账单里 RDS 按扫描行数计费——很多时候根因是一条或一类 SQL：缺索引、全表扫描、隐式类型转换，或 ORM 里经典的 N+1。单靠「加索引试试」容易误伤写入路径，也说不清 EXPLAIN 里 type、rows、Extra 到底在暗示什么。
技能如何工作
本技能把 SQL 优化当成可重复的模式，而不是零散技巧。你会先明确目标、约束和输入（表规模、读写比、能否改 schema、是否允许冗余索引），再按场景套用相关最佳实践，并给出可验证的步骤：例如用 EXPLAIN / EXPLAIN ANALYZE 对比前后计划、关注 key、rows、filtered、是否出现 Using filesort / Using temporary。
核心覆盖方向包括：
- 调试运行缓慢的查询，定位是索引、统计信息还是 SQL 写法问题
- 设计更利于查询的数据库模式（选择性、联合索引列顺序、覆盖索引思路）
- 实现高效索引，避免重复索引与低选择性单列索引
- 分析并改写查询计划，减少回表与临时表
- 识别并消除 N+1 等应用层放大数据库压力的模式
- 在数据量增长时评估可扩展性（分页、深分页、批量加载）
需要更完整的模式与示例时，技能会指向 resources/implementation-playbook.md 中的实现手册。
适用边界
任务与 SQL / 数据库查询优化无关时不必启用本技能；也不替代特定引擎的运维（主从延迟、分库分表中间件选型、备份恢复）或安全审计。边界内的工作应始终用实测计划与指标验收，而不是只改语法「看起来更快」。
使用场景
- 生产接口 P99 突然升高，需在只读库上对可疑 SQL 跑 `EXPLAIN`，判断是缺索引、统计信息过期还是写法导致全表扫描。
- 新列表页联调时 APM 显示单次请求触发上百条相似 `SELECT`，要在 ORM 层定位并消除 N+1 查询。
- 单表行数即将破千万，要设计联合索引列顺序并改写深分页，避免 `OFFSET` 越大越慢。
- 云数据库账单里扫描行数异常偏高，要列出 TOP 慢 SQL，给出索引与改写方案并用执行计划前后对比验收。
适合人员
- 负责订单/报表等核心 API 的后端工程师，要在不改动业务语义的前提下把慢查询压进 SLA。
- 维护 MySQL 或 PostgreSQL 的 DBA，需评审开发提交的索引 DDL，避免重复索引与大表在线变更风险。
- 日常使用 Django、Hibernate 等 ORM 的全栈开发者，接口耗时随列表条数线性变差且日志里查询条数暴涨。
- 负责云 RDS 成本与稳定性的平台/SRE，要把全表扫描类 SQL 改成可量化、可回滚的优化项。
相关技能
约定 Spring REST 接口：HTTP 方法语义、统一 HttpResult 包装、Controller 不 try-catch、由全局异常处理输出。
专注开发者点文件与本地工具，按 SCAN→VERIFY 流程安全配置 shell、终端、编辑器与点文件管理。
在不改变运行时行为的前提下，为代码库补充 JSDoc/TSDoc、README、API 文档与类型清晰度，并支持覆盖率审计与文档腐烂检测。
发布 Skill 前的检查工具：按场景对 SKILL.md 做安全、多平台与运行依赖等检查并输出修复报告。