核心差异：区间裁剪 vs 均匀散列
RANGE分区与HASH分区的本质区别在于数据落盘逻辑。RANGE分区依据分区键的连续数值区间将数据划分到不同物理文件中，要求分区表达式返回整数或日期类型，且必须显式定义每个分区的边界值（如LESS THAN）。其优势在于天然契合范围查询与生命周期管理，例如按月份归档历史数据时可直接DROP PARTITION，无需逐行删除。HASH分区则通过内置哈希函数对分区键进行取模运算，将数据均匀打散至指定数量的分区中，要求键值必须为整型或可转换为整型的表达式。两者在查询与扩容上差异显著：RANGE在匹配范围条件时能精准裁剪分区，但新增分区需手动维护边界；HASH能有效避免写入热点，实现I/O负载均衡，但范围查询会触发全分区扫描，且调整分区数量通常需要重建表或重组数据，扩容成本较高。
场景决策：时间归档还是负载均衡？
业务场景是决定分区策略的核心依据。对于日志记录、监控指标或订单流水等具有强时间属性的数据，优先选择RANGE分区。例如按年或月划分，既能加速近期高频查询，又能通过定期清理旧分区释放空间。对于用户画像、会话表或高并发写入的订单主表，若查询多基于主键或用户ID进行等值匹配，且需避免单点写入瓶颈，HASH分区更为合适，它能将请求均匀分散至多个底层文件。需要特别强调的是，绝不能仅因表数据量突破千万级就盲目启用分区。若业务查询未携带分区键，或频繁执行跨分区JOIN与聚合，分区反而会引入额外的元数据开销与锁竞争，导致性能劣化。决策前必须结合执行计划与读写比例综合评估。
落地实施：语法规范与迁移风险
创建分区表需严格遵循语法规范与存储引擎限制。RANGE建表示例为：CREATE TABLE logs (id INT, create_time DATE, PRIMARY KEY(id, create_time)) PARTITION BY RANGE (YEAR(create_time)) (PARTITION p2022 VALUES LESS THAN (2023), PARTITION p2023 VALUES LESS THAN (2024));。HASH建表则为：PARTITION BY HASH(user_id) PARTITIONS 8;。分区键必须包含在主键或唯一索引中，这是InnoDB的硬性要求。分区数量规划上，RANGE依数据保留周期设定，HASH建议设为2的幂次以优化取模分布。对已有大表实施分区时，ALTER TABLE会触发全表重建并持有元数据锁，需提前评估磁盘空间、备份数据，并确认innodb_file_per_table已开启。生产环境建议在低峰期执行，或使用pt-online-schema-change等工具平滑迁移。
验证与避坑：裁剪失效与扩容陷阱
验证分区是否生效需依赖执行计划与系统视图。执行EXPLAIN SELECT * FROM orders WHERE create_time = '2023-10-01';，观察partitions列若仅显示目标分区名，说明分区裁剪成功。同时可查询INFORMATION_SCHEMA.PARTITIONS核对各分区行数分布是否均衡。常见设计误区包括：分区键未出现在WHERE条件中导致全表扫描；RANGE边界未严格递增或未设置MAXVALUE兜底，引发插入失败；HASH分区数量设置过多（如超千个），显著增加内存元数据负担与DDL耗时；HASH扩容无法直接ADD PARTITION，必须通过REORGANIZE重建；最后需明确分区并非性能银弹，它仅缩小扫描范围，若缺乏合理索引或SQL写法不当，整体响应时间仍会恶化。
