一键巡检 9 大类 50+ 检查项，3 秒定位锁等待，20 秒生成完整 Markdown 巡检报告。从「敲 SQL 敲到手抽筋」到「一句命令搞定一切」，就差这个 skill。

---

为什么要做这个 Skill？

做 DBA 或运维的兄弟应该都懂这种痛——

半夜告警响了，你眯着眼爬起来，连上 MySQL，开始敲：

SHOW PROCESSLIST;
SELECT * FROM information_schema.innodb_trx;
SELECT * FROM performance_schema.data_lock_waits;
SHOW ENGINE INNODB STATUS\G
-- ... 手抖敲错了还得重来

写得多了，你可能会存一些 SQL 脚本放到某个角落里，但到了真正用的时候，「那个查锁等待的 SQL 我放哪了？」「这个查慢查询的 SQL 在 MySQL 5.7 和 8.0 里还不一样」……然后又回到手敲的路上。

于是有了 mysql-ops-8.0 这个 skill——把 50+ 个常维检查 SQL 封装成一个可交互、可一键巡检的运维工具包。

另类玩法：

# 如果现网数据库不方便连接AI，可将这个SKILL安装在你的内网数据库主机中
bash scripts/run_ops_query.sh run_all ./report
巡检完成: ./report/mysql-inspection-2026-06-04-174352.md

#然后将./report/mysql-inspection-2026-06-04-174352.md 下载下来，发给AI工具做深度分析

---

它能干什么？

一句话：9 大类、50+ 项检查，支持按需查询和全自动巡检。

分类	覆盖内容	典型场景
📋 实例信息	版本、参数、插件、字符集	接手新实例第一件事
💾 容量管理	库大小、大表、碎片、自增 ID、无主键表	磁盘告了，谁吃掉的？
🔗 连接会话	来源分布、活跃/空闲连接	连接数飙了，谁在连？
🔒 锁与事务	行锁等待链、MDL 锁、死锁、活跃事务	业务卡了，谁锁了谁？
⚡ SQL 性能	慢查询、全表扫描、无索引 SQL、未使用索引	接口慢，哪条 SQL 有问题？
🛢️ InnoDB	引擎状态、行锁统计、Buffer Pool	InnoDB 内部发生了什么
🔄 主从复制	从库状态、半同步、延迟、Binlog	主从断了，从哪接上？
🔐 安全	账号列表、密码过期、认证插件	安全合规检查
📊 性能快照	全局状态变量一览	拿基线，看趋势

---

快速上手

1. 配置连接

vi ~/.workbuddy/skills/mysql-ops-8.0/assets/db_config.env

填入你的 MySQL 信息：

MYSQL_HOST=10.xx.xx.xx
MYSQL_PORT=3306
MYSQL_USER=root
MYSQL_PASSWORD=******

2. 单条查询

# 查锁等待
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh row_lock_waits

# 查慢查询 Top 10
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh slow_sql_top10

# 查哪些表没主键
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh no_pk_tables

3. 一键巡检

#存放当前目录
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh run_all

#指定存放目录
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh ./report

跑完生成 mysql-inspection-YYYY-MM-DD-HHmmss.md，9 大类全部覆盖，直接 Markdown 渲染看板。

---

实战：用这个 Skill 巡检一台生产库

以我实际巡检 10.xx.xx.80:3306（MySQL 8.0.46）为例，跑完 run_all 后直接挖出了几个藏得很深的问题。

🔴 问题一：DELETE 慢到离谱，根因藏了三层

巡检报告"SQL 性能分析"里直接暴露了：

| db      | query                                              | avg_latency |
| wgcloud | DELETE FROM `SYS_LOAD_STATE` WHERE `CREATE_TIME`.. | 1.62s       |
| wgcloud | DELETE FROM `NETIO_STATE` WHERE `CREATE_TIME`..    | 1.57s       |
| wgcloud | DELETE FROM `MEM_STATE` WHERE `CREATE_TIME`..      | 1.42s       |
| wgcloud | DELETE FROM `CPU_STATE` WHERE `CREATE_TIME`..      | 1.33s       |

然后看「全表扫描排行」：

| db      | table_name     | rows_full_scanned |
| wgcloud | sys_load_state | 39,324,621        |
| wgcloud | netio_state    | 15,283,082        |

再看「数据库大小列表」：

| SCHEMA | total_mb | free_mb | 碎片率 |
| wgcloud| 206.54   | 839.00  | 406%   |

三层数据串起来，根因就出来了：

CREATE_TIME 列缺索引 → DELETE 全表扫描 → 每次扫描扫出大量空洞 → 碎片越积越多 → DELETE 越来越慢（恶性循环）

如果只查一张表、只跑一条 SQL，很容易只看到"DELETE 慢了"或"碎片多了"，但很难把这三层关系串成因果链。巡检报告把容量 + 性能 + 物理存储同时看完，根因一目了然。

---

🟠 问题二：Buffer Pool 才 128MB，但你都不知道

| innodb_buffer_pool_size | 134217728 |  -- 128MB

这台库数据总量 226MB，128MB BP 只能缓存不到 60% 的热数据。更要命的是——wgcloud 的全表扫描 DELETE 在不断把热数据从 BP 里踢出去（Buffer Pool 污染），命中率虽然写着 99.96%，但 Innodb_buffer_pool_reads = 64998 意味着物理读还是不少。

修复也简单：SET GLOBAL innodb_buffer_pool_size = 536870912; 一条命令搞定。

---

🟠 问题三：你敢信？24 张表没主键

| db         | TABLE_NAME                       |
| n9e_v6     | task_scheduler                   |
| n9e_v6     | task_host_doing                  |
| imsobserva | monitor_minute_request           |
| imsobserva | monitor_starttime_endpoint_stats |
| ... (还有 20 张)                         |

InnoDB 的表没有主键，MySQL 会自己造一个隐藏的 6 字节 ROW_ID。看着能用，但：

• 写入时每次都要维护这个隐藏列
• ROW 格式 binlog 下，UPDATE/DELETE 只能全表扫描定位行，复制延迟翻倍
• 很多在线 DDL 操作直接不支持

这些坑不查不知道，一查吓一跳。

---

安装方式

# 如果已经有 WorkBuddy skill 环境，skill 文件已在：
ls ~/.workbuddy/skills/mysql-ops-8.0/

# 配置连接后直接用
vi ~/.workbuddy/skills/mysql-ops-8.0/assets/db_config.env
bash ~/.workbuddy/skills/mysql-ops-8.0/scripts/run_ops_query.sh run_all


# 如果现网数据库不方便连接AI，可将这个SKILL安装在你的内网数据库主机中
bash scripts/run_ops_query.sh run_all ./report
巡检完成: ./report/mysql-inspection-2026-06-04-174352.md

#然后将./report/mysql-inspection-2026-06-04-174352.md 下载下来，发给AI工具做深度分析

最低权限要求：

GRANT SELECT ON *.* TO 'ops_user'@'%';
GRANT PROCESS, REPLICATION CLIENT, SHOW DATABASES ON *.* TO 'ops_user'@'%';

---

最后

做运维这个行当，工具永远不嫌多。一个好的工具不是它能做多少事，而是在火烧眉毛的时候，你能不能 3 秒之内想起来怎么用它。

mysql-ops-8.0 的设计目标就是这个：场景分类清晰、一条命令直达、输出格式统一。不用翻文档，不用手敲 SQL，不用记参数。

如果你也在用 WorkBuddy 做 MySQL 运维，试试看。有问题、有想法、想加新的检查项，随时来聊。

---

写于 2026-06-04，巡检了一台跑了 11 天的 8.0.46 实例，发现了 839MB 碎片、4 条秒级 DELETE、24 张无主键表。这些问题在你下一次巡检之前，很可能已经藏了很久了。