MySQL 8.0+ 不支持对已有 RANGE 分区表添加哈希子分区，必须重建表；需用 PARTITION BY RANGE COLUMNS(...) SUBPARTITION BY HASH(...) 重新定义，并注意主键、自增、边界值等约束。
MySQL 8.0+ 支持哈希子分区吗？
不支持。mysql 的 range 分区表无法直接添加哈希子分区（即复合分区中的 subpartition by hash），哪怕是在 8.0+ 版本里。alter table ... partition by 不允许在已有分区表上变更分区类型，更不允许从单级 range 升级为 range columns + subpartition by hash 这类复合结构。
想实现“按时间范围分大区、再按用户ID哈希打散”怎么办？
只能重建表。MySQL 没有在线修改分区逻辑的机制，ALTER TABLE ... REORGANIZE PARTITION 只能调整现有分区边界或合并/拆分同类型分区，不能引入子分区。
- 导出原表数据（用
mysqldump --no-create-info或SELECT ... INTO OUTFILE） - 用新 DDL 创建目标表：明确写
PARTITION BY RANGE COLUMNS(created_at) SUBPARTITION BY HASH(user_id) SUBPARTITIONS 4 - 注意字段顺序：
RANGE COLUMNS要求分区列必须是DATE/DATETIME类型且不可为 NULL；HASH子分区只接受整数表达式，user_id必须是整型，不能是VARCHAR - 导入数据后，手动重建索引、外键、触发器等附属对象
为什么不能直接 ALTER TABLE ... PARTITION BY？
因为 MySQL 将分区定义视为表元数据的强约束，修改它等于重定义物理存储布局。引擎层（InnoDB）不提供就地转换分区策略的能力——这不同于加字段或改索引，后者可在线做，但分区重组必须锁表并重写全部数据文件。
- 执行
ALTER TABLE t PARTITION BY ...会报错：ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function（即使你没动主键，只要分区函数变了，主键就必须覆盖所有分区列） - 如果原表主键不含
created_at和user_id，你得先DROP PRIMARY KEY，再加符合要求的联合主键，否则 DDL 直接失败 -
pt-online-schema-change也救不了——它底层仍是拷贝+同步，而分区表的INSERT ... SELECT在子分区场景下可能触发非预期的路由错误，必须人工校验每条数据落到了正确的子分区
重建时最容易漏掉的三件事
不是语法写对就能跑通。真实迁移中，90% 的问题出在细节断层。
- 原表如果有
AUTO_INCREMENT字段，新表必须显式指定auto_increment_offset和auto_increment_increment，否则多子分区下自增 ID 可能冲突 -
SHOW CREATE TABLE输出的分区定义里，RANGE边界值是包含上限还是排除上限？MySQL 默认是“左闭右开”，比如VALUES LESS THAN (20240101)不包含 2024-01-01 零点，但你的业务时间字段如果是DATETIME，就得确认是否要写成LESS THAN (20240101000000) - 子分区数量（
SUBPARTITIONS N）一旦定下就不能改——后续想扩容只能再重建，所以一开始就要按未来 2 年数据量预估，别图省事写SUBPARTITIONS 2
INFORMATION_SCHEMA.PARTITIONS，就可能多修半天数据倾斜。 
