一键巡检 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 PoolInnoDB 内部发生了什么 主从复制从库状态、半同步、延迟、Binlog主从断了从哪接上 安全账号列表、密码过期、认证插件安全合规检查 性能快照全局状态变量一览拿基线看趋势快速上手1. 配置连接vi ~/.workbuddy/skills/mysql-ops-8.0/assets/db_config.env填入你的 MySQL 信息MYSQL_HOST10.xx.xx.xx MYSQL_PORT3306 MYSQL_USERroot 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_tables3. 一键巡检#存放当前目录 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.md9 大类全部覆盖直接 Markdown 渲染看板。实战用这个 Skill 巡检一台生产库以我实际巡检10.xx.xx.80:3306MySQL 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这台库数据总量 226MB128MB 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 张无主键表。这些问题在你下一次巡检之前很可能已经藏了很久了。