高基数字段分组慢因分组桶数量爆炸，需降维（如提取邮箱域名）、建生成列+索引、用hll近似算法、强制哈希聚合并调大内存参数，或改用top-n子查询规避全量分组。
高基数字段分组为什么慢？
因为分组桶数量爆炸。比如对 user_email 或 order_id 这类唯一值接近行数的字段做 GROUP BY，MySQL 不得不维护上万甚至百万个分组状态，内存撑不住就会写磁盘临时表——EXPLAIN 里一看到 Using temporary 就基本确认是这问题。
先降维再分组：用衍生字段替代原始高基数列
直接对原始高基数字段分组几乎总是错的。真正要统计的往往不是“每个邮箱”，而是“每个域名”或“每类用户”。
- 把
GROUP BY user_email改成GROUP BY SUBSTRING_INDEX(user_email, '@', -1)（提取域名），再给该表达式建生成列 + 索引 - 对 UUID 字段，可提前计算
MD5(user_id)前 8 位作为分桶标识，或用LEFT(user_id, 4)截取前缀 - 避免在
GROUP BY中直接写函数，否则索引失效；应建生成列并加索引：ALTER TABLE users ADD COLUMN email_domain VARCHAR(64) STORED AS (SUBSTRING_INDEX(user_email, '@', -1))，再CREATE INDEX idx_email_domain ON users(email_domain)
用近似算法替代精确分组
当业务允许误差（比如“去重用户数”而非“具体是谁”），优先选 HLL（HyperLogLog）这类概率算法。
- PostgreSQL 可直接用
approx_count_distinct()或HLL_ADD() - MySQL 8.0+ 无原生 HLL，但可用
COUNT(DISTINCT)配合WHERE缩小范围，或引入 Redis HyperLogLog 做预聚合 - 注意：
COUNT(DISTINCT high_cardinality_col)本身也会触发临时表，必须搭配前置过滤和覆盖索引，否则比GROUP BY还慢
强制走哈希聚合，绕过排序开销
MySQL 默认倾向用索引排序实现分组，但对高基数字段，哈希聚合（hash aggregation）通常更高效——前提是数据能全进内存。
- 关掉隐式排序：
ORDER BY NULL必须显式加上，否则即使没写ORDER BY，MySQL 仍会按分组字段排序 - 调大
tmp_table_size和max_heap_table_size（例如设为 256M），让哈希表尽量留在内存 - 但别无脑调大：超过物理内存会触发 swap，反而更慢；重点是先用
WHERE把输入行压到 10 万以内再分组
LIMIT + 子查询或物化 CTE 提前筛出候选集，比硬扛全量高基数分组快一个数量级。
