在处理亿级表的GROUP BY统计时，索引设计、数据裁剪和预计算这三大要点必须紧密配合，缺一不可。否则，COUNT(DISTINCT)操作极有可能引发临时表的急剧膨胀以及磁盘排序，严重影响性能。而导致这一问题的核心瓶颈，就在于数据库执行过程中的各种隐式开销，其中包括：去重操作引发的磁盘排序、回表时的随机IO、全表扫描以及索引失效等。

直接说结论：亿级表的 GROUP BY 统计不能靠“写对SQL”就搞定，必须配合索引设计、数据裁剪、预计算三板斧，否则哪怕加了索引，COUNT(DISTINCT) 依然会触发临时表膨胀和磁盘排序。

为什么 GROUP BY 在亿级表上容易慢？

核心不是分组动作本身，而是数据库执行时的隐式开销：

• COUNT(DISTINCT) 必须去重，MySQL/Oracle 默认走 Using temporary; Using filesort，内存撑不住就刷到磁盘，IO飙升；
• 没覆盖索引时，GROUP BY 需回表读原始行，亿级扫描+随机IO是性能黑洞；
• 如果 WHERE 条件没走索引，先全表扫描再分组，等于把10亿行全拉进内存排队；
• 复合索引列顺序错（比如建了 (time, channel) 却只查 channel），索引直接失效。

必须建的复合索引怎么设计？

不是“给 GROUP BY 字段加索引”就行，得按查询模式反推。以交易流水表 BANK_OPER 为例：

• 典型查询带 WHERE OPER_TIME BETWEEN ... AND ... AND BIZ_CHANNEL IN (...) + GROUP BY BIZ_CHANNEL；
• 最优索引是 INDEX idx_time_channel (OPER_TIME, BIZ_CHANNEL, SERIAL_ID, PAY_ACCT, ENTERPRISE_CODE, OPER_AMOUNT)；
• 前两列满足最左前缀用于过滤，后四列覆盖所有聚合字段，避免回表；
• 注意：SERIAL_ID 等字段放索引里只为覆盖，不参与排序，所以顺序无关紧要；
• 别用 TEXT 或大字段建索引，会拖慢索引构建和更新。

怎么避免 COUNT(DISTINCT) 拖垮查询？

这是亿级统计最常卡死的点，光靠索引解决不了：

• 业务允许误差时，用近似函数：MySQL 8.0+ 可用 APPROX_COUNT_DISTINCT(SERIAL_ID)，PostgreSQL 用 approx_count_distinct()；
• 不允许误差但查询频次高，提前建预聚合表：每天凌晨跑一次 INSERT INTO daily_channel_stats SELECT BIZ_CHANNEL, COUNT(DISTINCT SERIAL_ID), ... FROM BANK_OPER WHERE OPER_TIME = '2026-08-11' GROUP BY BIZ_CHANNEL；
• 硬要实时查，把 DISTINCT 拆成两层：先用子查询按渠道抽样 ID 列表，再在外层 GROUP BY 计数，减少中间集大小；
• 绝对不要在 WHERE 里对索引列用函数，比如 WHERE DATE(OPER_TIME) = '2026-08-11' —— 这会让整个时间索引失效。

分区表和统计信息容易被忽略的细节

分区不是银弹，用错反而更慢：

• 按 OPER_TIME 分区时，必须确保 WHERE 条件能精准命中分区（如 BETWEEN '2026-08-01' AND '2026-08-31'），否则会扫全部分区；
• 分区后仍要对每个分区建局部索引，全局索引在分区表上效果差；
• 统计信息过期会导致优化器选错执行计划：执行 DBMS_STATS.GATHER_TABLE_STATS（Oracle）或 ANALYZE TABLE（MySQL）后，再查 EXPLAIN 确认 rows 估值是否合理；
• 别信“自动收集”，尤其在批量导入后，手动触发一次统计更新比等自动任务靠谱得多。

你知道吗？真正让亿级分组统计陷入困境的，并非语法或逻辑本身，而是索引覆盖情况、COUNT(DISTINCT)是否被当作黑盒硬算、分区裁剪是否生效。这三个方面只要有一处没处理好，查询时间就会从秒级飙升到分钟甚至小时级。

《夸克》非常好用的免费AI浏览器

下载APP查看