information_schema.tables 的 table_rows 对 InnoDB 表仅为估算值，误差大且不实时；MyISAM 才精确，但已基本淘汰。可靠方法是动态生成 SELECT COUNT(*) 语句批量执行，或 ANALYZE TABLE 后查 table_rows（仍有延迟和锁表问题）。
为什么直接查 information_schema.tables 的 table_rows 不准？
MySQL 的 information_schema.tables 表里确实有 table_rows 字段，但它对 InnoDB 表只是**估算值**，尤其在表有频繁增删、没做 ANALYZE 或使用了旧版本 MySQL（如 5.7 之前）时，误差可能高达 50% 甚至返回 NULL。MyISAM 表才保证精确——但如今几乎没人用 MyISAM 了。
所以，别信 table_rows，除非你明确知道当前库是 MyISAM，或刚执行过 ANALYZE TABLE 且能接受误差。
如何用 SELECT COUNT(*) 批量查所有表行数？
最可靠的方式还是对每张表执行 COUNT(*)。手动写 N 条语句太傻，用 information_schema 动态拼 SQL 即可：
SELECT CONCAT('SELECT ''', table_name, ''' AS table_name, COUNT(*) AS row_count FROM `', table_schema, '`.`', table_name, '`;')
FROM information_schema.tables
WHERE table_schema = 'your_db_name'
AND table_type = 'BASE TABLE';
把结果复制出来执行，或者用 MySQL 客户端的批处理模式（如 mysql -e "..." | mysql your_db_name）。注意：大表会锁读、耗 I/O，别在高峰期跑。
- 务必替换
your_db_name为真实库名，且该库名不能含特殊字符（否则要加反引号） - 加
AND engine = 'InnoDB'可过滤掉视图或临时表 - 如果某张表权限不足，对应语句会报错，不影响其他表执行
有没有更快但依然靠谱的折中方案？
对大多数线上 InnoDB 表，SHOW TABLE STATUS 比 information_schema.tables 稍准一点，因为它会触发一次轻量级采样；而更实用的是结合 ANALYZE TABLE 后再查 table_rows：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
ANALYZE TABLE t1, t2, t3;
再查：
SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'your_db_name'
AND table_name IN ('t1','t2','t3');
这个方法快，但仍有两个硬伤：
-
ANALYZE TABLE本身会加表级读锁（InnoDB 是元数据锁，通常很快，但大表仍可能阻塞 DDL） - 即使分析完，
table_rows也不会实时更新——后续写入后又不准了
脚本化统计时容易忽略的关键点
写自动化脚本（Python/Shell）批量查行数时，这几个细节不处理就会翻车：
- 表名含连字符、空格或大小写混合时，必须用反引号包裹：
`my-table`，否则 SQL 报错 - MySQL 默认
max_allowed_packet可能不够，拼超长 SQL 会截断，建议设大点：SET GLOBAL max_allowed_packet = 64*1024*1024; - 不要用
SELECT COUNT(1)替代COUNT(*)——优化器虽常等价，但某些旧版本或特定索引结构下，COUNT(1)可能绕过优化，变慢 - 如果库中有分区表，
information_schema.tables会把每个分区当独立表列出来，需加AND create_options NOT LIKE '%partitioned%'过滤
真正需要精确数字时，没捷径。估算快但不准，COUNT 快不了但准——选哪个，取决于你此刻是在做容量规划，还是在 debug 数据丢失。
