range分区适合时间或有序数值冷热分离，list适用于枚举值维度，hash/key用于均匀分布；三者均需分区键含于主键，且裁剪依赖条件是否匹配分区键。
RANGE 分区适合按时间或有序数值做冷热分离
当你的查询大量集中在最近几天/月份的数据，而历史数据只用于归档或低频分析时，RANGE 是最直观的选择。它依赖列值的连续范围划分，天然适配 datetime、int 这类单调增长字段。
常见错误现象：ERROR 1659 (HY000): Field 'created_at' is of a not allowed type for partitioning —— 比如用了 timestamp（MySQL 5.7+ 支持，但早期版本不支持），或对 varchar 做 RANGE（语法允许但语义混乱，实际几乎没人这么干）。
使用场景：
- 日志表按
YEAR(created_at)或TO_DAYS(created_at)分区 - 订单表按
order_id千万级分段（如VALUES LESS THAN (10000000)）
注意点：
-
MAXVALUE必须作为最后一个分区的上限，漏写会导致ALTER TABLE ... REORGANIZE PARTITION失败 - 新增分区需手动
ALTER TABLE ... ADD PARTITION，不能自动扩展 - 查询带
WHERE created_at BETWEEN '2024-01-01' AND '2024-06-30'时，优化器大概率能裁剪到对应 2–3 个分区，但若条件含函数如DATE(created_at)，分区裁剪可能失效
LIST 分区适用于明确有限枚举值的业务维度
LIST 不是“按区间”，而是“按枚举值列表”——比如国家代码、业务线代号、状态码这类离散且可穷举的字段。它比 RANGE 更灵活地处理非连续值，但不如 HASH 均匀。
常见错误现象：ERROR 1520 (HY000): Reorganize of range or list partitions cannot change total number of partitions —— 想通过 REORGANIZE 合并两个 LIST 分区时，必须保证所有被合并分区的值都放进新分区定义里，漏一个值就报错。
使用场景：
- 用户表按
region_id（如 1=华北, 2=华东, 3=华南）分区，各区域数据量差异大，但运维希望按区域独立备份 - IoT 设备表按
device_type（'thermostat', 'camera', 'sensor'）分区，不同设备类型读写模式差异明显
关键限制：
- 每个值只能属于一个分区，重复值会报错
ERROR 1521 (HY000): Duplicate entry in list partitioning - 不能用表达式，必须是常量：允许
VALUES IN (1,2,3)，不允许VALUES IN (region_id + 1) - 新增值需
ALTER TABLE ... ADD PARTITION (PARTITION p4 VALUES IN (4))，无法像RANGE那样预建未来分区
HASH 和 KEY 分区本质都是取模，但 KEY 能用多列且自动处理 NULL
HASH 和 KEY 都靠哈希函数把值映射到固定数量的分区，目标是让数据尽可能均匀分布。区别在于：HASH 只接受单列且要求你提供整型表达式（如 YEAR(created_at)），而 KEY 可直接用字符串列、支持多列、内部用 MySQL 自研哈希算法，且对 NULL 值有明确定义（一律路由到分区 0）。
常见错误现象：ERROR 1658 (HY000): Cannot use non integer column in HASH/KEY partitioning —— 对 email VARCHAR(255) 直接写 PARTITION BY HASH(email) 会失败；必须改用 KEY(email)。
使用场景：
- 用户表按
user_id哈希分 16 个区，避免单表过大，同时保持关联查询（如JOIN订单表）时分区对齐可能性 - 会话表用
PARTITION BY KEY(session_id, app_version)，兼顾主键分散性和多维筛选需求
性能提示：
-
HASH的表达式如果计算开销大（如HASH(MD5(user_email))），会影响 INSERT 性能；KEY内部哈希更快 - 分区数建议设为 2 的幂（如 4/8/16/32），否则取模后分布容易倾斜
-
KEY在 MySQL 8.0+ 对JSON列不支持，别踩坑
选错分区类型会导致查询变慢甚至锁表
分区不是银弹。最常被忽略的一点：分区裁剪（partition pruning）是否真生效，得看 EXPLAIN PARTITIONS 输出里的 partitions 列——如果显示 all 或远超预期数量，说明优化器没识别出过滤条件与分区键的关系。
典型翻车现场：
- 用
RANGE分区的表，查询条件是WHERE DATE(created_at) = '2024-05-01'，因函数导致分区键失效 - 用
LIST分区的表，WHERE status IN ('pending','success')中某个值不在任何分区定义里，查不到数据还不出错，静默返回空结果 - 误以为
HASH能加速LIKE 'abc%'查询——它只对等值查询有效，范围或模糊匹配无法裁剪
另一个硬约束：PRIMARY KEY 或 UNIQUE KEY 必须包含分区键，否则建表直接报错 ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function。这意味着想按时间分区，又想用 id 当主键？得改成复合主键 (id, created_at)，或者放弃主键强制要求（不推荐）。
事情说清了就结束
