MySQL 健康体检样例报告：8.0.46 测试库绿黄红评分，digest 被锁等待抬到 2.001 秒
在 MySQL 8.0.46 测试库跑一套只读体检清单：连接与 abort、长事务/锁等待、performance_schema digest Top、InnoDB dirty/history list、表体积；无从库则复制标 N/A。给出绿/黄/红规则与完整样例报告（自造 9999/99999/99999 行）。附复现脚本、只读 SQL、CSV/Markdown 报告。
MySQL 8.0.46 测试库 mysql_hc_lab（自造 accounts 9999、orders 99999、order_items 99999，2026-10-27）：连接占用 0.7%（1/151）、Aborted_connects=0 → 绿；采集时无长事务 → 绿；digest 最大平均耗时 2.001 秒（其实是 timeout=2 的锁等待 UPDATE，不是 SQL 本身慢）→ 黄；dirty 0.01%、History list 18 → 绿；无从库 → 复制 N/A。总体黄。正式 ¥499 体检按约定证据出 P0/P1/P2，本页只展示评分形态。
适用对象
- 样例总体等级 YELLOW：六维里慢查询为黄，其余已评分为绿，复制未测标 N/A。
- digest Top1 的 UPDATE avg=2.001s 与 ERROR 1205（innodb_lock_wait_timeout=2）同一场景——黄灯要先看 SUM_LOCK_TIME / 锁等待，再谈改 SQL。
- History list length=18、dirty_pages=5/65536（0.01%）在本测试实例上是绿；无从库时复制维度写 N/A，不要假装测过。
- 下载区有一键 lab 脚本、只读巡检 SQL、CSV 与 Markdown 样例报告；生产请用只读账号跑 SQL，脚本只许 *_lab 库。
绿 / 黄 / 红怎么划（本样例口径）
正式客户包用 P0/P1/P2 并要求证据编号；本页用绿黄红，方便自己先跑一轮。总体取「已评分维度」的最差色，N/A 不参与。
| 维度 | 绿 | 黄 | 红 |
|---|---|---|---|
| 连接与 abort | 占用 <70% 且 Aborted_connects≤100 | 占用≥70% 或 abort>100 | 占用≥90% 或 abort>1000 |
| 长事务 / 锁等待 | 无 ≥30s 事务且无等待 | 有 ≥30s 或当前有锁等待 | 有 ≥300s 或等待≥10 |
| 慢查询 digest | 最大 AVG <1s | ≥1s | ≥5s |
| InnoDB | history list <1e5 且 dirty%<40 | history≥1e5 或 dirty≥40% | history≥1e6 或 dirty≥75% |
| 表/索引体积 | 本样例只列 Top，不因体积标红 | — | 生产另按磁盘余量 |
| 复制 | 有从库且延迟正常 | 延迟偏高 | 中断；无从库 → N/A |
一张表看完：总体 YELLOW
采集瞬间 threads_connected=1 / max_connections=151（0.7%），Aborted_connects=0，Aborted_clients=2。长事务 max_age=0，data_lock_waits=0。InnoDB dirty_pages=5/65536（0.01%），History list length=18。replica_channels=0。
唯一拉黄的是 digest：lab 流量里最大 AVG=2.001 秒。表体积 order_items 17.55MB、orders 11.55MB、accounts 1.52MB，lab 体量小，标绿。
| 维度 | 关键数字 | 等级 |
|---|---|---|
| 连接与 abort | 1/151（0.7%）；abort_connects=0；abort_clients=2 | GREEN |
| 长事务 / 锁等待 | 采集时 age=0、waits=0；制造时曾 waits=1 且 1205 | GREEN |
| 慢查询 digest | 最大 AVG=2.001s（锁等待 UPDATE） | YELLOW |
| InnoDB | dirty 0.01%；History list=18 | GREEN |
| 表/索引体积 | 见上；lab 小表 | GREEN |
| 复制 | replica_channels=0 | N/A |
| 总体 | 最差已评分 = 黄 | YELLOW |
digest 2.001 秒其实是锁等待，不是 JOIN 慢
我先把 innodb_lock_wait_timeout 调到 2，会话 A 更新 accounts id=1 后 SLEEP 4 秒。会话 B 去改同一行：lock_snap 里 data_lock_waits=1，GRANTED / WAITING 都是 X,REC_NOT_GAP，LOCK_DATA=1；B 报 ERROR 1205。
TRUNCATE digest 后再看 Top：UPDATE accounts … balance+? 的 AVG/MAX 正好 2.001 秒，SUM_LOCK_TIME 也是 2 秒。真正的 JOIN 聚合只有 0.128 秒、扫约 20 万行。若只看「平均耗时」就会误判要加索引。
事后全局 Innodb_row_lock_time_avg=4100（毫秒量级累计均值）、Innodb_row_lock_waits=10——说明锁等待统计和 digest 要一起看。站内另有 1205 阻塞链专文，可对照。
本节判断
- digest Top（截断）：SLEEP avg 1.268s；锁等待 UPDATE 2.001s；JOIN GROUP BY 0.128s（rows_examined 200002）。
- 只读 SQL 第 3–5 段：data_lock_waits、innodb_trx、events_statements_summary_by_digest。
History list 18、无从库就写 N/A
SHOW ENGINE INNODB STATUS 里 History list length=18；Log sequence number 与 Last checkpoint 几乎贴在一起（采集时差约几百，稍后复查已追平）。dirty 只有 5 页。按规则这是绿——测试实例很闲，正式体检还会看趋势，不会只看一个点。
performance_schema.replication_connection_status 计数为 0：这台没有从库。样例报告复制维写 N/A，而不是编一条「复制正常」。有从库时再查 Seconds_Behind_Source / 权限错误。
脚本只许 *_lab；生产只用只读 SQL
下载 lab 脚本：会 DROP/CREATE mysql_hc_lab、造数、打 1205、输出 Markdown 评分。默认 BIN=/opt/mysql/bin、mysql -uroot。DB 名必须以 _lab 结尾，否则直接退出。
生产环境请跑只读 SQL（已过只读守卫：无 INSERT/UPDATE/KILL/SET GLOBAL）。History list 与 checkpoint 仍需另开 SHOW ENGINE INNODB STATUS，把数字贴进报告。把结果脱敏后，可以当作 ¥499 体检的材料草稿。
觉得有用？转给正在做这件事的同事或朋友
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
这份 MySQL 体检样例总体是什么等级？
YELLOW。2026-10-27 在 MySQL 8.0.46 测试库 mysql_hc_lab 上，连接/长事务/InnoDB/体积为绿，digest 最大 AVG 2.001 秒为黄，无从库复制为 N/A。
为什么慢查询维度是黄，JOIN 却只有 0.128 秒？
拉高平均值的是一条等锁的 UPDATE：innodb_lock_wait_timeout=2 时精确等了 2.001 秒后报 1205，digest 的 AVG/LOCK_TIME 同步变成 2 秒。
History list length 多少算红？
本样例口径：≥100000 黄，≥1000000 红。本次测到 18，属绿。正式体检还会结合趋势与 undo 压力，不单看一个瞬时值。
没有从库怎么办？
复制维度标 N/A，并在报告里写明「未配置 / 未测」。不要写成绿灯。
样例报告和 ¥499 体检有什么区别？
样例展示只读采集与绿黄红形态。正式体检在约定证据内输出 P0/P1/P2、证据缺口、未覆盖项和整改 Top5，备份恢复与权限相关结论由合格人员复核。