count(*)在超大表上卡死因innodb需全扫描聚簇索引并逐行校验mvcc可见性，亿级数据耗时数分钟；推荐主键步进采样估算（误差
为什么 COUNT(*) 在超大表上会卡死或超时
因为 InnoDB 引擎下 COUNT(*) 默认走聚簇索引全扫描，哪怕加了 WHERE 1=1 也绕不开——它必须逐行确认可见性（MVCC），数据量过亿时可能耗时数分钟甚至触发 lock_wait_timeout 或被 KILL。这不是 SQL 写得不对，是引擎机制决定的。
常见错误现象：SHOW PROCESSLIST 显示状态为 Sending data 长时间不动；EXPLAIN 显示 type: ALL 且 rows 估不准；监控看到磁盘 I/O 持续拉满。
- 不要依赖
information_schema.TABLES.TABLE_ROWS，这个值是估算值，InnoDB 下误差常达 ±50%，且不反映 MVCC 可见行数 - 避免在业务高峰期执行裸
SELECT COUNT(*) FROM big_table - 如果表有频繁写入，统计中途还可能因长事务导致一致性视图膨胀，进一步拖慢速度
用 MIN() + MAX() + 主键步进采样逼近真实值
当主键是自增 BIGINT 且无大量删除/空洞时，可利用主键连续性做低成本估算，再通过小范围精确校验收敛到真实值。比全表扫快 10–100 倍，误差可控在 0.1% 以内。
实操步骤：
- 先查主键范围：
SELECT MIN(id), MAX(id) FROM big_table（毫秒级） - 按步长（如 10000）抽样检查是否存在空洞：
SELECT COUNT(*) FROM big_table WHERE id BETWEEN 100000 AND 110000 - 若多段抽样都接近步长，则总行数 ≈
MAX(id) - MIN(id) + 1；若发现某段严重不足（如只返回 200 行），说明存在删除空洞，需对该段SELECT COUNT(*)精确补算
注意：该方法不适用于 UUID 主键、逻辑删除未物理清理、或频繁 REPLACE/INSERT ... ON DUPLICATE KEY UPDATE 的场景。
建汇总表或使用 ROLLUP 触发器实时维护计数
如果业务上需要高频查询总行数（比如后台管理页每刷一次都要查），硬扛 COUNT(*) 是反模式。应该把“统计”变成“记录”。
- 新建一张轻量表：
CREATE TABLE table_row_count (table_name VARCHAR(64) PRIMARY KEY, row_count BIGINT NOT NULL DEFAULT 0) - 对目标表增删操作统一走存储过程，或在应用层用事务包裹
INSERT/DELETE和对应UPDATE table_row_count - 如必须用触发器，注意性能损耗：每个
INSERT都会额外一次UPDATE，高并发写入时可能成为瓶颈
这个方案牺牲了“绝对实时”，但换来了毫秒响应。只要保证事务一致性（例如用 FOR UPDATE 锁住计数行），误差始终为 0。
MySQL 8.0+ 可尝试 INFORMATION_SCHEMA.INNODB_TABLESTATS 辅助判断
这个表里的 N_ROWS 字段仍是估算值，但相比老版本更贴近实际（基于采样页的统计信息）。关键在于它更新及时——只要执行过 ANALYZE TABLE，就能反映近期数据分布变化。
- 查前先刷新统计：
ANALYZE TABLE big_table（注意：会加表级读锁，建议低峰期执行） - 再查：
SELECT N_ROWS FROM INFORMATION_SCHEMA.INNODB_TABLESTATS WHERE NAME = 'database_name/big_table' - 如果业务能接受 ±5% 误差，且无法改代码或建汇总表，这是最快捷的折中方案
别忘了路径名是 database_name/table_name 格式，不是纯表名；且该表默认对普通用户不可见，需授权 SELECT 权限。
真正难的不是选哪个方法，而是想清楚：你到底要“精确到个位数的最终答案”，还是“足够支撑决策的可靠近似值”。前者永远要成本，后者往往有更轻的解法。
