MySQL分区表：RANGE与HASH分区选择

理解RANGE与HASH分区的核心差异

RANGE分区依据分区键的连续数值区间将数据划分到不同物理文件中，要求分区表达式返回整数或日期类型，且必须显式定义每个分区的边界值（如LESS THAN）。其优势在于天然契合范围查询与生命周期管理，例如按月份归档历史数据时可直接DROP PARTITION，无需逐行删除。HASH分区则通过内置哈希函数对分区键进行取模运算，将数据均匀打散至指定数量的分区中，要求键值必须为整型或可转换为整型的表达式。两者在查询与扩容上差异显著：RANGE在匹配范围条件时能精准裁剪分区，但新增分区需手动维护边界；HASH能有效避免写入热点，实现I/O负载均衡，但范围查询会触发全分区扫描，且调整分区数量通常需要重建表或重组数据，扩容成本较高。

根据业务场景选择分区方式

业务场景是决定分区策略的核心依据。对于日志记录、监控指标或订单流水等具有强时间属性的数据，优先选择RANGE分区。例如按年或月划分，既能加速近期高频查询，又能通过定期清理旧分区释放空间。对于用户画像、会话表或高并发写入的订单主表，若查询多基于主键或用户ID进行等值匹配，且需避免单点写入瓶颈，HASH分区更为合适，它能将请求均匀分散至多个底层文件。需要特别强调的是，绝不能仅因表数据量突破千万级就盲目启用分区。若业务查询未携带分区键，或频繁执行跨分区JOIN与聚合，分区反而会引入额外的元数据开销与锁竞争，导致性能劣化。决策前必须结合执行计划与读写比例综合评估。

实际创建与配置RANGE、HASH分区

创建分区表需严格遵循语法规范与存储引擎限制。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写法不当，整体响应时间仍会恶化。