怎样优化MySQL千万级大表的Count(*)查询速度_利用Redis或元数据表做实时计数-mysql教程-PHP中文网

count(*)在千万级表上慢因innodb全表扫描且无缓存；可用redis（双写+校准）或元数据表（on duplicate key优化）替代，但带where条件时需索引或近似统计。

怎样优化mysql千万级大表的count(*)查询速度_利用redis或元数据表做实时计数

因为 InnoDB 引擎下 COUNT(*) 默认走聚簇索引全扫描（哪怕有主键），不走二级索引优化，且无法利用查询缓存（MySQL 8.0 已移除）。当表行数超 1000 万、QPS 较高时，单次 COUNT(*) 可能卡住 2–5 秒，还容易阻塞其他 DML 操作。

适合写多读少、允许短暂误差（秒级）的场景，比如「当前在线用户数」「文章总浏览量」。关键不是存总数，而是控制好增减时机和原子性。

INCRBY 和 DECRBY 必须和业务 SQL 在同一事务中触发 —— 但 Redis 本身不参与 MySQL 事务，所以实际要靠应用层双写 + 补偿：先更新 MySQL，再 INCRBY；失败则记录日志，由后台任务重试
不要用 GET + SET 模拟原子增减，会丢数据；必须用 INCRBY
为防 Redis 宕机导致计数丢失，建议每天凌晨用 SELECT COUNT(*) FROM t 全量校准一次，写入 SET t:count:backup 作为兜底值
如果业务有「软删除」，记得在删除逻辑里同步 DECRBY 1；硬删除则通常已含该逻辑

比 Redis 更可靠，适合要求强一致的场景，比如「会员总人数」「待审核订单数」。本质是把聚合结果物化成一行一列的普通表。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

建表示例：

CREATE TABLE t_count (name VARCHAR(64) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0);

插入初始值：INSERT INTO t_count VALUES ('user_total', 0);

所有 INSERT/DELETE 都必须配套 UPDATE t_count SET cnt = cnt + 1 WHERE name = 'user_total'（或 -1），推荐封装进存储过程或 ORM hook
避免在高并发写入点直接 UPDATE ... SET cnt = cnt + 1 —— 会引发行锁争用；改用 INSERT INTO t_count VALUES ('user_total', 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1，利用唯一索引+插入冲突机制降低锁粒度
如果业务有批量导入，别循环执行 N 次 UPDATE，应先算出增量 Δ，再单条 UPDATE t_count SET cnt = cnt + ?

当查询带 WHERE 条件（如 COUNT(*) WHERE status = 1 AND created_at > '2024-01-01'），Redis 和元数据表都无能为力 —— 它们只适合全表或固定条件的计数。此时更务实的做法是：

给高频过滤字段加组合索引，让 COUNT(*) 走覆盖索引扫描（例如 INDEX(status, created_at)）
用近似统计：SELECT table_rows FROM information_schema.tables WHERE table_name = 't' AND table_schema = 'db'，误差可能达 10%～20%，但毫秒级返回
对超大范围分页计数，直接放弃精确总数，改用「加载更多」模式，避免 LIMIT offset, size 导致的深度偏移问题

真实线上环境里，最常被忽略的是「软删除字段未索引」和「元数据表没加 FOR UPDATE 或乐观锁」—— 这两类小疏漏，足以让计数在高峰期悄悄漂移。