SHOW TABLE STATUS会触发表元数据锁并刷新InnoDB统计信息，导致DML卡顿、锁等待及链式阻塞；其非纯只读，可能同步扫描索引页或空闲页链表，大表下延迟显著；应改用带条件的information_schema查询或缓存方案。
SHOW TABLE STATUS 会触发表元数据锁和统计刷新
执行 SHOW TABLE STATUS 时，MySQL 必须获取该表的 MDL_SHARED_READ 元数据锁，并强制刷新 InnoDB 表的统计信息（如 table_rows、Data_free），尤其在未开启 innodb_stats_persistent 或使用采样估算的老版本中，这会引发一次同步的、阻塞式的统计收集过程。
常见错误现象包括：
- 大表执行
SHOW TABLE STATUS后，后续 DML 操作明显卡顿几秒甚至十几秒 - 配合
information_schema.tables查询时出现长时间等待Waiting for table metadata lock - 在高并发写入场景下，多个
SHOW TABLE STATUS请求排队，形成锁链式阻塞
InnoDB 统计刷新不是“只读”操作
很多人误以为 SHOW TABLE STATUS 是纯只读命令，但它对 InnoDB 表实际会触发以下动作：
- 若
innodb_stats_on_metadata = ON（MySQL 5.6 默认开启，5.7+ 默认 OFF），每次执行都会重新扫描索引页估算行数和碎片 - 即使关闭该选项，首次访问某表的
SHOW TABLE STATUS仍可能触发惰性统计加载，尤其当表刚被FLUSH TABLES或重启后 -
Data_free值来自ibdata1或独立表空间的空闲页链表扫描，对几十 GB 的大表可能耗时数百毫秒
性能影响取决于表大小和磁盘 I/O 能力。一个 200GB 的订单表，在机械盘上执行一次 SHOW TABLE STATUS 可能带来 800ms+ 的延迟抖动。
替代方案：用 information_schema + 缓存规避实时扫描
生产环境应避免在监控脚本或 API 中直接调用 SHOW TABLE STATUS，改用更轻量的方式：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查询
information_schema.tables并加 WHERE 条件限定库名和表名，比通配LIKE快得多 - 对核心大表，把关键字段（
table_rows、data_length、index_length、data_free）定时（如每 5 分钟）采集到本地缓存表，业务层查缓存而非实时扫 I_S - 检查是否启用了
innodb_stats_persistent = ON和innodb_stats_auto_recalc = OFF，避免写入频繁时自动重算干扰 - 确认
innodb_stats_method = nulls_unequal（默认）是否合理；某些业务场景下设为nulls_equal可减少统计偏差导致的误刷
容易被忽略的细节：FLUSH TABLES WITH READ LOCK 会放大问题
如果在执行 SHOW TABLE STATUS 前刚执行过 FLUSH TABLES WITH READ LOCK，那么后续所有 SHOW TABLE STATUS 都会被阻塞，直到锁释放——因为元数据锁升级冲突。这不是命令本身的问题，而是锁生命周期管理没对齐。
更隐蔽的是：某些备份工具（如 mysqldump --single-transaction）内部会悄悄执行 SHOW TABLE STATUS 获取表结构，若此时恰好有长事务或锁等待，就会拖慢整个备份流程。
真正要注意的，不是“能不能用”，而是“谁在什么时候、以什么频率、对哪些表在用”。一个没加 WHERE 的定时任务每分钟扫一遍 information_schema.tables，比单次手动执行 SHOW TABLE STATUS 危害大得多。
