MySQL PARTITION BY HASH 的数据分布为什么不均

MySQL 的 PARTITION BY HASH 并不会承诺每个分区的行数永远相等。普通 HASH 分区会把分区表达式的整数结果按分区数取模，数据分布是否均匀，首先取决于表达式结果和真实业务键值，而不是分区语法本身。低基数、热点值、把日期压成年份、NULL 集中到零号分区，都会让某个分区明显偏大。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

排查时先回答两个问题：每一行最终参与 HASH 的值是什么？这些值除以分区数后的余数是否真的分散？只看“已经建了 8 个分区”无法证明数据会均匀。

先用 MOD 规则解释数据落点

MySQL 8.4 文档给出的普通 HASH 规则可以简化成 N = MOD(expr, num)。例如下面的表有 8 个分区，customer_id 是表达式，8 是分区数：

CREATE TABLE orders (
    id BIGINT NOT NULL,
    customer_id INT NOT NULL,
    amount DECIMAL(12, 2) NOT NULL,
    PRIMARY KEY (id, customer_id)
)
-- 用客户编号的整数结果选择 8 个 HASH 分区
PARTITION BY HASH(customer_id)
PARTITIONS 8;

因此 customer_id=1、9、17 的余数都是 1，它们都会落在同一个分区编号上。分区数增加后，余数空间变大，但不会自动改变原始值的频率；一个本来就很热的客户仍然可能把大量数据送到同一个分区。

还要留意 NULL。对于 HASH 或 KEY 分区，分区表达式得到 NULL 时，MySQL 会按 0 处理，所以大量 NULL 会集中到 p0。如果业务允许空分区键，必须把它当作一个真实的数据分布类别，而不是认为它会被随机摊开。

四类原因会把数据推向少数分区

标题中的“不均”通常不是一个单独故障，而是键分布与映射规则叠加后的结果。可以按下面的顺序判断：

另外，不要把 LINEAR HASH 当成“更均匀的 HASH”。官方文档明确说明，线性 HASH 方便按 2 的幂次扩展，但数据相较普通 HASH 更不容易均匀。若当前使用的是线性分区，先确认扩容便利是否值得接受分布代价。

用分区元数据和分桶查询定位热点

先观察分区层面的行数和空间，确认是不是单个分区承担了明显更多的数据。对 InnoDB 来说，TABLE_ROWS 更适合作为趋势指标，不能替代精确的业务统计：

SELECT
    PARTITION_NAME,
    TABLE_ROWS,
    DATA_LENGTH,
    INDEX_LENGTH
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'orders'
  AND PARTITION_NAME IS NOT NULL
ORDER BY PARTITION_ORDINAL_POSITION;
-- 先看各分区的行数和空间趋势，不把估算值当成精确账目

再用与建表完全一致的表达式做分桶。下面的写法把 customer_id 的余数作为逻辑桶，先验证“偏斜发生在键值层还是分区层”：如果某个余数桶已经很热，原因在业务数据；如果逻辑桶较均匀但分区空间差异很大，还要继续检查索引、历史数据和分区维护。

SELECT
    MOD(customer_id, 8) AS hash_bucket,
    COUNT(*) AS row_count,
    COUNT(DISTINCT customer_id) AS distinct_customers
FROM orders
GROUP BY MOD(customer_id, 8)
ORDER BY hash_bucket;
-- 用同一分区表达式统计余数桶，避免拿另一套规则误判

如果分区表达式是 YEAR(created_at)，就把查询中的表达式也写成 MOD(YEAR(created_at), 8)；如果允许 NULL，还要单独统计 created_at IS NULL。排查的关键是让诊断 SQL 与建表表达式一字不差。

按访问模式修复，不要只把 8 改成 16

修复顺序建议是：

1. 优先换成稳定且高基数的键。键值要能长期分散写入，并且满足分区表对主键、唯一键中包含分区列的限制；不要只为了“看起来随机”选择一个业务上不可过滤的字段。
2. 减少表达式的信息损失。把按年份、状态等低基数表达式与真实查询模式对照。如果查询主要按时间范围读取和清理，RANGE 往往比 HASH 更容易表达生命周期；如果主要按单个整数键等值访问，HASH 才更贴合。
3. 调整分区数前先看余数分布。改分区数会改变取模结果，不能当作无成本扩容；要把数据重分布、索引体积、DDL 锁影响和回滚路径一起纳入变更计划。
4. 把热点当作业务问题处理。如果一个客户、租户或设备本身占了大多数写入，增加分区仍可能只是把热点换一个编号。需要拆分热点租户、改变写入模型，或让业务访问绕开这个单一分区。

最后可以用一张决策表快速收敛：

常见问题

分区数越多，数据一定越均匀吗？

不一定。分区数只改变取模的模数，无法消除热点值、低基数表达式或大量 NULL。先统计表达式结果的频率，再决定是否调整。

为什么看起来建了 HASH，查询还是扫很多分区？

HASH 分区的裁剪更适合分区表达式上的整数等值条件；如果查询没有约束分区键，或条件无法化简为分区表达式的等值/短范围，优化器就没有足够信息排除其它分区。分区也不能替代普通索引。

KEY 分区能彻底解决 HASH 偏斜吗？

不能保证。KEY 由 MySQL 提供哈希函数，但原始业务频率仍然存在；一个键值占据大多数行时，换函数不会改变它的出现次数。它更适合不想维护自定义整数表达式、且希望使用服务器哈希逻辑的场景。

总结：MySQL HASH 分区的落点由表达式结果和分区数共同决定，数据均匀的前提是输入值本身有足够基数且频率分散。用 INFORMATION_SCHEMA.PARTITIONS 看趋势，再用同一表达式做余数统计，确认根因后再选择换键、换表达式、治理热点或改分区类型。