最准的是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引擎内部维护的采样统计信息，根本不用去碰实际的数据页。但也正因如此，它的误差范围常常在 ±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 / a vg_row_length来做一个粗略的量级判断（a vg_row_length在information_schema.TABLES中也能查到）。
说到底，行数统计这件事，本质上是一场权衡：你究竟需要的是“此时此刻的绝对真相”，还是一个“够用、不拖慢系统、且偏差可控的近似值”？答案取决于你手上的表有多大、查询频率有多高，以及一旦出错，你是否能接受重新计算的成本。
