哈希分区表必须指定高唯一性分区键优先选主键或唯一列分区数应为2的幂次以优化性能仅支持等值查询范围查询失效MySQL、Oracle、DM8语法差异大需按引擎适配。哈希分区表建表时必须指定分区键且该列值要尽量唯一哈希分区的核心是把 partition_key 的值喂给哈希函数再模上分区数决定落哪个分区。如果选了个大量重复的列比如 status 只有 0/1 两个值那所有数据全挤进 2 个分区里其他分区空转——这比不分区还糟。实操建议优先选主键或带唯一约束的列例如 user_id、order_id避免用 gender、is_deleted 这类低基数列若只有组合列才够唯一可用表达式 PARTITION BY HASH(year(create_time)*10000 month(create_time))MySQL 支持Oracle 不支持表达式得先建虚拟列再分区。分区数量不是越多越好推荐用 2 的幂次如 4/8/16/32哈希分区内部靠 MOD(hash_value, partition_count) 定位分区。当 partition_count 是 2 的幂时数据库能用位运算快速取模性能更稳非幂次数比如 6 或 12可能触发取模除法部分引擎还会隐式重映射导致分布失真。常见错误现象建了 PARTITIONS 6结果发现 p0/p1 数据量是其他分区的 2 倍扩容时从 8→9 个分区几乎全部数据重分布因哈希值映射关系全变DM8 中若不显式命名分区会自动生成 DMHASHPART0、DMHASHPART1 等但数量仍需是 2 的幂才保证底层散列均匀。哈希分区对等值查询友好但范围查询和 ORDER BY 几乎无效因为哈希打散后原本有序的值如时间、ID在物理存储上完全随机。查 WHERE user_id 12345 能精准定位单一分区但查 WHERE user_id BETWEEN 1000 AND 2000 就得扫全部分区——失去了分区剪枝能力。 AI Code Reviewer AI自动审核代码