高效计数应避免全表扫描，优先使用覆盖索引（如(status, id)）配合count(*)，并为高频只读场景引入redis或stats表缓存，同时区分count语义，大数据量下可采用估算或分片统计。
直接用 COUNT(*) 统计全表行数，在数据量大、并发高时容易成为性能瓶颈。真正高效的计数，不靠“硬扫”，而靠“不扫”或“少扫”——核心是计数缓存与覆盖索引的合理配合。
优先用覆盖索引避免回表
当执行 COUNT(字段) 或 COUNT(*) 且 WHERE 条件可走索引时，确保该索引“覆盖查询所需全部信息”。例如：
要统计 SELECT COUNT(*) FROM orders WHERE status = 'paid'，如果只有 status 单列索引，MySQL 仍可能回表确认行存在；但若建联合索引 (status, id)（或任意非 NULL 列），优化器大概率走索引扫描，不访问聚簇索引，速度提升明显。
关键点：
- 索引列包含 WHERE 条件列 + 至少一个 NOT NULL 列（如主键），才能支撑
COUNT(*)的覆盖扫描 - 避免在 COUNT 中使用可为 NULL 的字段（如
COUNT(user_id)），否则无法利用覆盖索引加速 - 用
EXPLAIN检查type是否为index或range，且Extra不含Using filesort或Using temporary
对高频只读计数场景启用缓存
比如“文章总数量”“用户注册总数”这类变化不频繁、但查询极频繁的指标，不应每次查都扫表。可用以下方式缓存：
方案一：应用层缓存（推荐）
用 Redis 存储计数值，初始值通过 SQL 一次性加载；增删记录时，同步 INCR/DECR 缓存值，并设合理过期时间兜底（如 1 小时）。注意事务一致性：在数据库事务提交后更新缓存，或用延迟双删策略降低不一致窗口。
方案二：数据库内缓存表
建一张小表 stats (key VARCHAR(50) PRIMARY KEY, value BIGINT, updated_at TIMESTAMP)，用 INSERT ... ON DUPLICATE KEY UPDATE 原子更新。适合不依赖外部中间件、且更新频次可控的场景。
不建议：
- 用触发器自动维护计数表（易成锁瓶颈、难调试）
- 定时任务异步刷新（实时性差，且定时任务本身可能堆积）
区分语义，选对 COUNT 形式
COUNT(*)、COUNT(1)、COUNT(pk) 在绝大多数引擎中性能一致，但 COUNT(col) 行为不同：
-
COUNT(*)：统计所有行（包括 NULL 字段的行），优化器可走最小索引 -
COUNT(col)：只统计col IS NOT NULL的行，若col允许 NULL，就无法用仅含其他字段的索引覆盖 - 明确业务意图：真要“非空数量”才用
COUNT(col)；否则一律用COUNT(*)
大数据量下的替代思路
当表超千万、且必须近实时总行数时，精确 COUNT(*) 本身就不现实。可考虑：
- 用
TABLE_ROWS（来自information_schema.TABLES）获取估算值，误差通常在 1%~10%，适合监控大盘 - 按时间分片统计：如每天写入量稳定，用“昨日总数 + 今日增量（从 binlog 或写入日志中聚合）”推算
- 采样估算：对超大表，用
SELECT COUNT(*) * 100 FROM t TABLESAMPLE SYSTEM (1)（PostgreSQL 支持，MySQL 8.0.23+ 也支持类似语法）快速估算
不复杂但容易忽略：一次合理的索引设计 + 一层轻量缓存，往往比调优 COUNT 语句本身更有效。
