在业务系统中，经常需要对百万级规模的表进行数据统计，最基础的需求就是统计表中符合条件的数据行数。如果直接使用简单的COUNT查询，很容易出现查询卡顿、耗时过长的问题，尤其是在数据量持续增长的情况下，这种性能问题会更加突出。因此掌握针对性的优化策略十分必要。
基础COUNT查询的性能问题
最常用的COUNT统计语句是直接查询全表或者带简单条件的行数，例如统计用户表中所有用户数量：
-- 全表统计 SELECT COUNT(*) FROM user_table; -- 带条件统计 SELECT COUNT(*) FROM user_table WHERE status = 1;
当user_table表的数据量达到百万级时，这类查询会触发全表扫描，数据库需要遍历所有数据行来判断是否符合条件，IO消耗和CPU消耗都会非常高，查询耗时可能达到数秒甚至数十秒，严重影响业务响应速度。
核心优化策略
1. 合理设计索引
索引是提升COUNT查询性能最有效的手段之一，需要根据统计的查询条件设计对应的索引。如果是统计满足某个条件的行数，可以为条件字段创建普通索引。
例如经常需要统计status为1的用户数量，可以为status字段创建索引：
-- 创建status字段的普通索引 CREATE INDEX idx_user_status ON user_table(status);
如果统计条件包含多个字段，可以创建联合索引，联合索引的字段顺序需要和查询条件的顺序一致，才能最大化利用索引。比如经常统计status为1且create_time在某一时间段内的用户数量，可以创建联合索引：
-- 创建联合索引，字段顺序和查询条件顺序一致 CREATE INDEX idx_user_status_create_time ON user_table(status, create_time);
需要注意，COUNT(*)和COUNT(1)在大多数数据库引擎中会优先使用索引覆盖扫描，而COUNT(具体字段)如果字段没有索引，仍然会触发全表扫描，因此如果只需要统计非空字段的行数，也需要为该字段创建索引。
2. 利用数据库特性优化
不同的数据库引擎有各自的特性可以提升COUNT统计性能，以MySQL的InnoDB引擎为例，虽然它不像MyISAM那样会单独存储表的总行数，但可以通过其他方式优化。
如果是统计全表行数，且业务可以接受近似结果，可以使用SHOW TABLE STATUS命令获取表的近似行数，这个命令不需要扫描全表，执行速度极快：
SHOW TABLE STATUS LIKE 'user_table';
返回结果中的Rows字段就是表的近似行数，适合对精度要求不高的场景。
对于PostgreSQL数据库，可以利用pg_class系统表获取近似行数：
SELECT reltuples FROM pg_class WHERE relname = 'user_table';
3. 业务层缓存统计结果
如果统计需求不需要实时最新的数据，可以在业务层引入缓存机制。例如在Redis中缓存统计结果，当表中的数据发生增删改操作时，同步更新缓存中的统计值，查询时直接从缓存获取结果，完全避免数据库查询。
简单的缓存更新逻辑示例：
// 用户新增时更新缓存中的用户总数
public void addUser(User user) {
// 插入用户数据
userDao.insert(user);
// 缓存中的用户总数加1
redisTemplate.opsForValue().increment("user_count_total", 1);
}
// 用户删除时更新缓存
public void deleteUser(Long userId) {
// 删除用户数据
userDao.deleteById(userId);
// 缓存中的用户总数减1
redisTemplate.opsForValue().decrement("user_count_total", 1);
}
4. 分表分库场景下的统计优化
如果百万级表已经做了分表分库处理，直接统计所有分表的数据会非常耗时，可以采用汇总表的方式。创建一个单独的汇总表，记录每个分表的统计结果，查询时只需要查询汇总表即可。
汇总表结构示例：
CREATE TABLE user_count_summary (
table_name VARCHAR(50) NOT NULL,
count_num BIGINT NOT NULL,
update_time DATETIME NOT NULL,
PRIMARY KEY (table_name)
);
每次分表数据变更时，同步更新对应分表的统计值到汇总表，查询全量数据时直接查询汇总表的count_num总和：
SELECT SUM(count_num) FROM user_count_summary;
不同场景的策略选择
可以根据实际业务需求选择合适的优化方案，以下是常见场景的推荐方案：
| 业务场景 | 推荐优化方案 |
|---|---|
| 需要实时精确统计，条件固定 | 为条件字段创建合适的索引 |
| 需要全表行数，可接受近似结果 | 使用数据库自带的近似行数查询命令 |
| 统计频率高，对实时性要求低 | 业务层缓存统计结果 |
| 表已经分表分库 | 使用汇总表记录分表统计结果 |
注意事项
- 不要盲目创建索引，索引会增加数据写入的开销，需要根据实际查询频率平衡索引数量和写入性能。
- 使用近似统计结果时，需要和业务方确认是否可以接受精度偏差，避免影响业务逻辑。
- 缓存统计结果时，需要处理好并发场景下的缓存一致性问题，避免统计结果出现错误。