select count()更准，因为information_schema.tables.table_rows对innodb表仅为估算值，依赖采样且不实时更新；而count()通过全表扫描获得精确行数，是唯一可靠方式。
为什么 SELECT COUNT(*) 比 INFORMATION_SCHEMA.TABLES 更准？
因为 INFORMATION_SCHEMA.TABLES.TABLE_ROWS 只是估算值，尤其在 InnoDB 表中几乎总是不准——它依赖统计采样，事务未提交、MVCC 快照、表刚 ANALYZE 过与否都会影响显示。真正需要精确行数时，SELECT COUNT(*) FROM table_name 是唯一可靠方式。
常见错误现象：TABLE_ROWS 显示 0 或远小于实际值，但 COUNT(*) 返回正确结果；执行 ANALYZE TABLE 后数值变化，但依然滞后或不一致。
- InnoDB 默认不维护精确行数，为避免每次查询都扫全表，用统计信息“猜”一个近似值
- MyISAM 表的
TABLE_ROWS才接近准确（因它实时维护行计数），但已基本淘汰 -
TABLE_ROWS值在SHOW TABLE STATUS和INFORMATION_SCHEMA.TABLES中来源相同，本质一样
怎么查 INFORMATION_SCHEMA.TABLES 里的行数字段？
可以查，但得清楚它只是参考。典型写法：
SELECT TABLE_NAME, TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'your_table';
注意几个关键点：
-
TABLE_SCHEMA必须指定数据库名，不能省略或用'' -
TABLE_ROWS对于 InnoDB 表，可能是NULL（某些 MySQL 版本）或一个粗略整数（如 123456，但实际可能是 123789） - 该查询本身不加锁，速度快，适合快速巡检“大概规模”，比如判断某表是否为空或明显膨胀
ANALYZE TABLE 能让 TABLE_ROWS 更准吗？
能稍微改善，但不解决根本问题。InnoDB 的统计信息更新是异步且采样式的，ANALYZE TABLE 只是触发一次重新采样，不代表立刻精确。
- 执行后，
TABLE_ROWS可能更接近当前值，但仍有误差（通常 ±10% 以内，但无保证） - 高并发写入场景下，采样期间的数据变动会导致结果过期
- 对大表执行
ANALYZE TABLE会加读锁、消耗 I/O，不是轻量操作 - MySQL 8.0+ 默认启用
innodb_stats_auto_recalc = ON，但自动更新仍基于采样
什么时候该信 TABLE_ROWS，什么时候必须跑 COUNT(*)？
看用途：监控趋势用前者，校验数据一致性或生成报表用后者。
- 运维看板展示“各表大致体量”——用
INFORMATION_SCHEMA，快且够用 - ETL 任务前确认源表是否为空——不能只看
TABLE_ROWS = 0，得SELECT COUNT(*) LIMIT 1或EXISTS - 迁移前后比对行数——必须两端都跑
COUNT(*)，否则可能漏掉几十万行 - 带 WHERE 条件的“有效行数”——
TABLE_ROWS完全无用，只能COUNT(*) WHERE ...
真正麻烦的是大表的 COUNT(*)：没索引时会全表扫描，耗时长、占资源。如果业务真频繁需要精确总数，得考虑加汇总表或用 ROLLUP 缓存，而不是反复查 INFORMATION_SCHEMA。
