直接查 information_schema 表慢且不准，因 MySQL 8.0+ 动态生成元数据、5.7 及更早依赖表锁，且 DATA_LENGTH 等字段未 ANALYZE TABLE 时严重滞后。
为什么直接查 information_schema 表会慢且不准
很多同学一上来就写 SELECT COUNT(*) FROM information_schema.TABLES，结果发现执行要十几秒，甚至超时。这不是因为数据量大，而是 information_schema 在 MySQL 8.0+ 默认是基于内存临时表动态生成的，每次查询都会触发元数据重载；5.7 及更早版本则依赖表锁，高并发下容易阻塞。更关键的是，某些字段（比如 DATA_LENGTH、INDEX_LENGTH）在未执行 ANALYZE TABLE 前可能严重滞后，导致空间统计失真。
实操建议：
- 对核心库，改用
performance_schema.table_io_waits_summary_by_table获取近期访问热度，比静态大小更有业务意义 - 需要准确空间指标时，先对目标表执行
ANALYZE TABLE `db`.`tbl`（注意：该操作会加 MDL 读锁，避开业务高峰） - 避免在存储过程中遍历全部
TABLES记录——用WHERE table_schema NOT IN ('mysql', 'performance_schema', 'sys')过滤系统库
如何让存储过程安全地遍历所有用户库并采集指标
硬编码库名不可扩展，用游标动态查又容易因权限不足或库名含特殊字符（如短横线、中文）报错。最稳妥的方式是先构造合法库名列表，再拼接 SQL 执行，而非直接 USE 切换上下文。
实操建议：
- 从
information_schema.SCHEMATA中筛选：WHERE schema_name REGEXP '^[a-zA-Z0-9_]+$'，排除非法命名库 - 用
CONCAT('SELECT "', schema_name, '" AS db_name, ... FROM ', schema_name, '.some_table')拼接语句，再通过PREPARE+EXECUTE执行，避免游标嵌套开销 - 每轮执行后检查
@@error_count，若非 0 则记录错误库名到日志表，不中断整个过程
SHOW TABLE STATUS 和 INFORMATION_SCHEMA.TABLES 选哪个
两者字段高度重合，但行为差异极大：SHOW TABLE STATUS 是语句级命令，返回实时状态（包括 Rows 的近似值），而 INFORMATION_SCHEMA.TABLES 是视图，部分字段（如 TABLE_ROWS）在 InnoDB 下始终是估算值，且不反映 MVCC 可见行数。健康检查真正关心的是“是否异常膨胀”“索引是否失效”，不是精确行数。
实操建议：
- 优先用
SHOW TABLE STATUS LIKE 'xxx'获取单表状态，它比查INFORMATION_SCHEMA快 3–5 倍（尤其在分库多表场景） - 若需批量采集，用
SELECT CONCAT('SHOW TABLE STATUS FROM `', table_schema, '` LIKE ''', table_name, '''') ...动态生成并执行，别试图一条 SQL 查完 - 警惕
Auto_increment值过大但无实际插入——这说明自增 ID 被大量回滚或删除，可能预示业务逻辑异常
存储过程里怎么存结果又不锁死监控表
直接 INSERT INTO health_log SELECT ... 容易因长事务拖慢主业务。更糟的是，如果存储过程中途失败，残留的脏数据会让下一次检查误判。
实操建议：
- 建一张带时间戳和批次号的临时结果表，例如
health_check_result_20240615_1423，用当前时间动态命名，避免并发冲突 - 所有采集结果先写入该临时表，最后统一
INSERT INTO health_log SELECT * FROM temp_table WHERE check_time > NOW() - INTERVAL 5 MINUTE - 存储过程末尾加
DROP TEMPORARY TABLE IF EXISTS temp_table，确保不留垃圾
复杂点在于跨库权限校验和字符集兼容性——比如某库用 utf8mb4_0900_as_cs，而日志表是 utf8mb4_general_ci，插入时可能隐式转换失败。这类细节不报错但丢数据，得提前用 SHOW CREATE DATABASE 校验后再拼 SQL。
