InnoDB健康需监控缓冲池命中率等4项核心指标，MyISAM则重在索引/数据文件完整性及索引缓存比；禁用innodb_status_output类日志开关，改用performance_schema精准查锁。
查 InnoDB 状态别只看 SHOW ENGINE INNODB STATUS
这条命令输出太长、格式混乱，且只反映执行瞬间的快照，容易漏掉持续性问题。真正要判断 InnoDB 健康，得盯住几个关键指标：缓冲池命中率、未刷新脏页数、行锁等待次数、事务平均时长。
实操建议：
- 用
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%'算缓冲池命中率：Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)，低于 99% 就该查是不是innodb_buffer_pool_size配小了 -
Innodb_buffer_pool_pages_dirty持续 > 1000 页，说明刷盘跟不上写入节奏，可能拖慢后续写操作 -
Innodb_row_lock_waits在 5 分钟内增长 > 50 次，基本可以确认存在热点行锁争用，得查SELECT * FROM information_schema.INNODB_TRX找长事务
MyISAM 表没事务，但崩溃后恢复很脆弱
MyISAM 不支持事务和行锁，它的“健康”核心就两点：索引文件是否损坏、数据文件是否被异常中断写入。一旦出问题，REPAIR TABLE 是最后手段，不是日常监控项。
实操建议：
- 定期检查
MyISAM表状态用CHECK TABLE table_name，返回status: OK才算过关；若报error: record is crashed，说明 .MYI 或 .MYD 文件已坏 - 监控
Key_reads / Key_read_requests比值，高于 0.01 表示索引缓存（key_buffer_size）严重不足，会频繁读磁盘 - 避免在 MyISAM 表上跑长查询+写入混合负载——它用表级锁，一个慢查询就能把整张表锁死
用 information_schema 查引擎分布，别靠 SHOW CREATE TABLE 逐个翻
想快速知道库里哪些表还在用 MyISAM（尤其老系统升级前），手动看每个表的建表语句效率极低，也容易漏。
实操建议：
- 一条 SQL 统计所有非 InnoDB 表：
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE engine != 'InnoDB' AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys'); - 注意
engine字段值是大小写敏感字符串，'innodb'（小写）查不到，必须用'InnoDB' - 如果结果里出现
engine = NULL，说明该表被损坏或元数据不一致，需优先处理
innodb_status_output 和 innodb_status_output_locks 开关要慎开
这两个配置项控制是否在错误日志里写入 SHOW ENGINE INNODB STATUS 的完整输出，看着方便，但线上环境一开就容易撑爆磁盘。
实操建议：
- 默认关闭（
OFF），仅在排查锁等待或死锁时临时打开，用完立刻关掉 - 开启后日志体积暴增，尤其
innodb_status_output_locks=ON会每秒记录所有锁信息，对高并发库几乎是灾难 - 替代方案更稳：用
performance_schema.data_locks查当前锁，用sys.innodb_lock_waits视图定位阻塞链，不依赖日志轮转
InnoDB 的“健康”不在单次命令输出有多全，而在指标是否持续落在合理区间；MyISAM 的“稳定”也不靠命令多好看，而在于有没有人在它上面做本不该做的操作——比如加事务、搞高并发更新。这两套逻辑混着用，最容易出事的地方，永远是人以为“差不多就行”的那个阈值。
