GROUP BY遇NULL时哈希表因需为每个NULL分配独立桶或标记位而异常膨胀，导致冲突率飙升、频繁重哈希甚至落盘；验证需查EXPLAIN中“Using temporary”及COUNT(*)与COUNT(col)差异，优化可采用COALESCE转换、部分索引或预过滤。
GROUP BY 遇到 NULL 值时哈希表怎么变大的
MySQL（及多数主流数据库）在执行 GROUP BY 时，若使用哈希聚合（Hash Aggregation），会把分组键的值作为哈希表的 key。而 NULL 在 SQL 中是特殊值——它不等于任何值，包括它自己。数据库必须把所有 NULL 视为“可能属于同一组”，但又不能简单地用相同哈希码处理，否则会违反语义（比如 NULL = NULL 不成立）。结果就是：多数引擎选择为每个 NULL 分配独立的哈希桶或额外标记位，导致哈希表实际条目数远超预期。
哪些场景下 NULL 会让 GROUP BY 性能断崖式下跌
不是所有含 NULL 的 GROUP BY 都慢，关键看数据分布和执行路径：
- 当分组字段中
NULL占比超过 15%～20%，哈希表冲突率飙升，触发频繁扩容和重哈希 - 如果该字段无索引，优化器大概率放弃排序聚合（Sort-based Aggregation），强制走哈希路径
- 在内存不足时，哈希表被迫落盘（
Using temporary），I/O 成为瓶颈，耗时呈指数增长 -
GROUP BY后接HAVING过滤，而条件里又涉及该字段（如HAVING COUNT(*) > 1），NULL 组无法提前剪枝，全量保留
怎么验证你的 GROUP BY 正被 NULL 拖慢
别猜，直接看执行计划和数据特征：
- 执行
EXPLAIN FORMAT=TRADITIONAL，检查Extra列是否出现Using temporary; Using filesort—— 这说明既没走索引也没走内存哈希，已退化为磁盘临时表 - 查
SELECT COUNT(*), COUNT(<code>your_col), COUNT(DISTINCTyour_col) FROM your_table，对比三者差距；若COUNT(*)显著大于COUNT(<code>your_col)，说明 NULL 很多 - 对字段做直方图分析：
ANALYZE TABLE your_table UPDATE HISTOGRAM ON your_col，再查information_schema.COLUMN_STATISTICS看 NULL 值频次估算
绕过 NULL 导致哈希膨胀的实操办法
核心思路不是“消灭 NULL”，而是让数据库能安全合并它们，或避开哈希路径：
- 显式转换：
GROUP BY COALESCE(<code>col, '__NULL__')，把 NULL 归为一个确定字符串；注意确保该字符串不在原始数据中出现 - 加覆盖索引：
CREATE INDEX idx_grp ON t(col) WHERE col IS NOT NULL（MySQL 8.0+ 支持函数索引或部分索引），让非 NULL 路径走索引扫描+排序聚合 - 预过滤：若业务允许，先
WHERE col IS NOT NULL再GROUP BY，避免 NULL 参与聚合计算 - 改用窗口函数替代：如只需 Top-N 聚合结果，可用
ROW_NUMBER() OVER (PARTITION BY col ORDER BY ...)配合外层LIMIT，跳过完整分组
真正麻烦的是那些既不能改 schema、又无法加索引、还要求 NULL 和非 NULL 必须同组统计的报表场景——这时哈希表膨胀就不是优化问题，而是架构约束下的硬代价。
