哈希分区核心是使数据均匀分布以避免单点压力，适用于等值查询为主且分片键高频出现在WHERE条件的场景；需选高基数、确定性整数表达式字段，避免NULL和函数包装，分区数建议4～32个且为2的幂次。
哈希分区不是“随便选个字段一哈希就完事”，它核心目标是让数据在多个分区中尽量均匀分布，从而避免单点压力过大。但用不好反而会拖慢查询，甚至让分区失效。
哈希分区适用的典型场景
适合数据访问模式以等值查询为主、且分片键高频出现在WHERE条件中的表。比如用户表按user_id哈希，订单表按buyer_id哈希，这样查某个用户的所有记录时，数据库只需访问1个分区。
- 读多写少、查询条件固定（如
WHERE user_id = 12345） - 没有明显时间或范围倾向的数据（不适合按日期查“最近7天”的场景）
- 需要规避热点问题——比如注册ID集中在某段区间时，范围分区容易压垮一个节点
分区键选择的关键原则
不是所有字段都适合做哈希键。选错会导致数据倾斜、查询变慢，甚至无法利用分区剪枝。
-
必须是确定性整数表达式：字段本身是INT/BIGINT最佳；DATE类需转为整数（如
YEAR(create_time)、TO_DAYS(date_col)），但避免用NOW()这类随机/非常量函数 - 高基数、分布较均匀：用户ID、订单号通常合适；状态码（只有0/1/2）、性别（M/F）就不行——哈希后大量数据挤进少数几个分区
-
避免NULL值参与哈希：MySQL中NULL会被统一映射到同一分区，易造成倾斜。建表前建议加
NOT NULL约束或预处理
分区数量设置的实用建议
分区数不是越多越好，也不是越少越省事。它直接影响I/O并发能力与管理成本。
- 一般从4～32个分区起步，常见取2的幂次（4/8/16/32），便于底层计算优化
- 不要盲目匹配物理CPU核数或磁盘数量——MySQL分区是逻辑拆分，不强制绑定硬件资源
- 超过64个分区需谨慎：元数据开销上升，
EXPLAIN PARTITIONS输出变长，部分DDL操作（如添加分区）可能变慢 - 如果未来要扩容，优先考虑重哈希迁移+应用层路由兼容，而不是临时加分区（哈希分区不支持像范围分区那样“追加”新分区）
常见错误与避坑提醒
很多性能问题其实源于写法或配置疏忽，而非分区本身。
-
WHERE里没用哈希键 → 全分区扫描：例如表按
user_id哈希，却执行SELECT * FROM t WHERE create_time > '2025-01-01'，MySQL无法剪枝，会扫所有分区 -
用函数包装哈希键 → 失效：写成
WHERE ABS(user_id) = 123或WHERE user_id + 0 = 123，可能导致优化器放弃分区裁剪 -
忘记加PARTITIONS子句：语句写成
PARTITION BY HASH(id)但没跟PARTITIONS 8，MySQL默认只建1个分区，等于白分 -
误把哈希当索引用：哈希分区不提供排序能力，也不加速
>、BETWEEN等范围查询——这类需求该用范围分区
基本上就这些。哈希分区本质是“负载均衡工具”，不是万能加速器。用对了，数据散得开、查询稳；用错了，只是把性能问题从单点转移到了多个点上。
