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(your_col), COUNT(DISTINCT your_col) FROM your_table，对比三者差距；若 COUNT(*) 显著大于 COUNT(your_col)，说明 NULL 很多
• 对字段做直方图分析：ANALYZE TABLE your_table UPDATE HISTOGRAM ON your_col，再查 information_schema.COLUMN_STATISTICS 看 NULL 值频次估算

绕过 NULL 导致哈希膨胀的实操办法

核心思路不是“消灭 NULL”，而是让数据库能安全合并它们，或避开哈希路径：

• 显式转换：GROUP BY COALESCE(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 必须同组统计的报表场景——这时哈希表膨胀就不是优化问题，而是架构约束下的硬代价。