最准的是COUNT(*)，但大表会卡；TABLE_ROWS是估算值，误差±40%～50%；触发器方案能实时但维护成本高；推荐定期ANALYZE TABLE并监控偏差。
直接用 COUNT(*) 是最准的，但大表会卡住
如果你要一个**绝对准确的数字**，比如做数据迁移核对、审计报告或上线前校验，count(*) 是唯一可靠的选择。它不依赖任何统计缓存，也不管引擎类型，全表扫描一遍就完事。
但代价很实在：一张千万级的 InnoDB 表执行一次 SELECT COUNT(*) FROM big_table，可能卡住几秒到几十秒，期间还可能阻塞其他写操作（尤其在低版本 MySQL 或未开启 innodb_stats_persistent 时）。
- 别加
LIMIT 1——COUNT(*)本身只返回一行，加了没用，还可能误导自己 - 避免在事务里长时间持有
SELECT COUNT(*)，容易引发锁等待 - 如果表有频繁写入，
COUNT(*)的结果只是“那一刻”的快照，不是实时值
information_schema.TABLES.TABLE_ROWS 是估算值，别当真
查 TABLE_ROWS 字段快得飞起，因为它读的是 InnoDB 存储引擎内部维护的采样统计（来自 dict_table_t::stat_n_rows），根本不用扫数据页。但正因如此，它的误差经常在 ±40%～50%，尤其在表刚大批量插入/删除后，还没触发自动 ANALYZE TABLE 时，数值可能完全失真。
-
TABLE_ROWS = 0不代表表空，可能是统计没更新，也可能是MyISAM表被截断过 - 对
MyISAM表，这个值反而是精确的（因为 MyISAM 把行数存在文件头），但 MyISAM 现在基本没人用了 - 不要用它做容量规划依据，比如“这表估 200 万行，我就按这个设分库分表”，大概率翻车
缓存行数（触发器方案）能实时，但维护成本高
有人建个 table_row_count 表，再配 AFTER INSERT/AFTER DELETE 触发器来实时更新计数。逻辑上没错，但实际落地问题一堆：
- 触发器本身有开销，每插/删一行都多一次
UPDATE，QPS 高时反而成瓶颈 - 没处理
TRUNCATE—— 这个命令会绕过触发器，导致缓存彻底错乱 - 没考虑事务回滚：触发器执行了，但事务最终
ROLLBACK，缓存就比实际多（或少）了 - 跨库、分区表、外键级联操作时，触发器逻辑极易漏覆盖
除非你有专职 DBA 能持续巡检和修复，否则不建议在生产环境长期依赖这套机制。
真正实用的折中方案：定期 ANALYZE TABLE + 监控偏差
与其在“绝对准确”和“完全不准”之间硬选，不如把 TABLE_ROWS 当作一个可管理的近似指标：手动或定时跑 ANALYZE TABLE，让统计值尽量贴近真实，并监控偏差趋势。
- 每天低峰期对核心大表执行
ANALYZE TABLE your_table，然后立刻查SHOW TABLE STATUS LIKE 'your_table'看Rows是否明显回升 - 写个简单脚本对比
TABLE_ROWS和最近一次COUNT(*)结果，偏差 >20% 就告警 - 对超大表（如日志表），干脆放弃“精确行数”执念，改用
data_length / avg_row_length做粗略量级判断（avg_row_length在information_schema.TABLES里也有）
行数统计这件事，本质是权衡：你要的是“此时此刻的真相”，还是“够用、不拖慢系统、能追得上的近似”。选哪个，取决于你手上的表有多大、多久查一次、以及出错后能不能接受重算。
