菜单
解读慢查询的 EXPLAIN 输出,给中文优化建议(索引/扫描行数/回表/filesort/临时表)。当用户说「EXPLAIN 帮我看下/这个查询好慢/SQL 优化/慢查询分析/explain 结果看不懂」时触发。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
把 Claude Code 汉化 —— 让 Claude 默认用中文回复,并给每个工具调用加中文 tooltip 提示。当用户想"汉化 Claude Code""让 Claude 说中文""装中文命令提示""localize Claude Code to Chinese"时使用。
列出可清理的本地分支(已合并 / 陈旧),供用户确认后再删。当用户说"清理分支 / 哪些分支可以删 / 列出过期分支 / 整理 git 分支 / 哪些分支可以清掉"时触发。
把一个函数/代码片段/diff 写成一首俳句或打油诗,抓住代码的「神韵」。当用户说「给这段代码写首诗」、「code-haiku」、「把这个函数写成俳句」、「这个 diff 怎么用诗表达」时触发。
把一个文件的修改史讲成故事——谁、何时、为何改了它。当用户说「讲讲这个文件的故事 / git-blame-story / 这个文件经历了什么 / 追溯文件历史 / 帮我看看这个文件的来龙去脉」时触发。
扫描 Dockerfile 的体积/安全/缓存/最佳实践问题并给出中文修法。当用户说"帮我检查 Dockerfile / Dockerfile 有没有问题 / 审查 Dockerfile / dockerfile-doctor"时触发。
按表结构 / struct / TS interface / JSON shape 生成假数据与测试种子数据,支持 JSON / SQL INSERT / CSV / NDJSON 输出格式。触发词:/mock-data-gen、帮我生成测试数据、帮我造数据、生成假数据、生成种子数据。
| name | sql-explain-zh |
| description | 解读慢查询的 EXPLAIN 输出,给中文优化建议(索引/扫描行数/回表/filesort/临时表)。当用户说「EXPLAIN 帮我看下/这个查询好慢/SQL 优化/慢查询分析/explain 结果看不懂」时触发。 |
把 MySQL EXPLAIN 输出收敛成"每行的中文含义 + 具体能做什么优化",不用再对着英文文档猜。
EXPLAIN 输出(含 id/select_type/table/type/key/rows/Extra 等列)# 设置连接环境变量(标准 MYSQL_* 变量)
export MYSQL_HOST=127.0.0.1
export MYSQL_PORT=3306
export MYSQL_USER=root
export MYSQL_PASSWORD=secret
export MYSQL_DATABASE=mydb
# 跑 EXPLAIN(SQL 作参数)
bash <skill>/bin/explain.sh "SELECT * FROM orders WHERE user_id = 1"
# 或从 stdin 传 SQL
echo "SELECT * FROM orders WHERE user_id = 1" | bash <skill>/bin/explain.sh
脚本输出 EXPLAIN 结果后,把输出粘给 Claude 解读。
直接把 EXPLAIN 结果粘给 Claude,说"帮我解读这个 EXPLAIN"即可。无需脚本。
bin/explain.sh 跑出来。## EXPLAIN 解读
### 查询概览
（一句话:这是什么查询、预期扫哪几张表、关联逻辑）
### 逐行分析
| 行 | table | type | key | rows | Extra | 风险 |
|----|-------|------|-----|------|-------|------|
| 1 | orders | ALL | NULL | 500000 | Using filesort | 🔴 全表扫描 + filesort |
| 2 | users | eq_ref | PRIMARY | 1 | — | ✅ 主键等值 |
**各列说明：**
- **type**（访问类型,从优到劣）：
`system` > `const` > `eq_ref` > `ref` > `range` > `index` > `ALL`
- `ALL`：全表扫描,**最差**,rows 大时必须加索引。
- `index`：索引全扫,比 ALL 好但仍可能慢。
- `range`：索引范围扫描,`WHERE id BETWEEN 1 AND 100` 之类。
- `ref`：非唯一索引等值匹配。
- `eq_ref`：唯一索引等值,JOIN 时常见。
- `const`/`system`：最优,主键/唯一索引点查。
- **key**：实际用到的索引;`NULL` = 没用任何索引。
- **rows**：预估扫描行数,越大越慢。
- **Extra**（常见危险信号）：
- `Using filesort`：ORDER BY 用不上索引,需额外排序。
- `Using temporary`：用了临时表,GROUP BY/DISTINCT/子查询常见。
- `Using index`：覆盖索引,不回表,✅ 好事。
- `Using where`：Server 层再过滤,索引后还有额外筛选。
- `Using join buffer`：JOIN 没有走对端索引,内存 Buffer 处理。
### 问题 & 优化建议
1. **问题一：<table> 全表扫描(type=ALL,rows=500000)**
- 原因：WHERE 条件列 `user_id` 无索引。
- 建议：`ALTER TABLE orders ADD INDEX idx_user_id (user_id);`
- 预期效果：rows 从 500000 → 约 N,type 变 ref。
2. **问题二：Using filesort**
- 原因：ORDER BY `created_at` 与过滤条件不在同一复合索引。
- 建议：`ADD INDEX idx_user_created (user_id, created_at);`（复合索引覆盖过滤+排序）
- 预期效果：Extra 消去 Using filesort。
3. **回表说明**（若适用）
- key 列命中二级索引但 SELECT 了非索引列,需回表查主键行。
- 建议：把高频 SELECT 列加进覆盖索引,或只 SELECT 需要的列。
### 结论
（总结:最大瓶颈在哪、优先做哪一件事、预估改完后扫描行数量级变化）
SHOW CREATE TABLE 就不猜索引列类型/选择度,需要时明确问用户。ALTER/CREATE/DROP 语句,建议以注释块形式呈现。EXPLAIN 的情况下承诺"性能提升 X 倍"。EXPLAIN 格式;PostgreSQL EXPLAIN ANALYZE 格式不同,可解读但需说明。bin/explain.sh 只跑 EXPLAIN(不跑 EXPLAIN ANALYZE),不对生产数据库做任何写操作。