ALTER TABLE ... PARTITION BY 直接失败，因MySQL要求分区列必须被所有唯一索引（含主键）覆盖，普通表通常不满足；唯一可靠方式是CREATE新分区表+INSERT迁移+RENAME原子切换。
ALTER TABLE ... PARTITION BY 会直接失败
MySQL 不支持对已有数据的普通表直接用 ALTER TABLE ... PARTITION BY 添加分区。执行时会报错：ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function（或类似提示），哪怕表没主键也会卡在约束校验阶段。本质是 MySQL 的分区 DDL 要求：分区列必须被所有唯一索引（含主键、UNIQUE）覆盖，而普通表结构通常不满足该前提。
实操建议：
- 先检查原表索引：
SHOW CREATE TABLE t1;，确认主键/唯一索引是否包含拟用作分区键的列（如created_at） - 若不包含，必须先
DROP PRIMARY KEY或重建索引（注意外键依赖） - 即使索引满足条件，
ALTER TABLE t1 PARTITION BY RANGE (YEAR(created_at)) (...)在 8.0+ 仍大概率失败——这是 MySQL 的已知限制，不是操作失误
唯一可靠方式：CREATE + INSERT + RENAME
绕过 DDL 限制的通用解法是重建表。核心思路是建新分区表 → 导入旧数据 → 原子切换。关键点不在“怎么建分区”，而在“怎么切得安全”。
实操建议：
- 新建分区表时，必须严格复刻原表结构（含字符集、排序规则、索引、注释），仅追加
PARTITION BY子句。例如：CREATE TABLE t1_new LIKE t1;<br>ALTER TABLE t1_new PARTITION BY RANGE (TO_DAYS(created_at)) (<br> PARTITION p2023 VALUES LESS THAN (TO_DAYS('2024-01-01')), <br> PARTITION p2024 VALUES LESS THAN (TO_DAYS('2025-01-01'))<br>); - 用
INSERT INTO t1_new SELECT * FROM t1;迁移数据。注意：若原表有自增主键，新表会继承值；若数据量大，考虑分批插入并加COMMIT - 切换前停写原表（如应用层下线写流量），再执行：
RENAME TABLE t1 TO t1_old, t1_new TO t1;。这是原子操作，无锁表风险
分区键选择不当会导致查询变慢
很多人以为加了分区就自动加速查询，实际恰恰相反。如果 WHERE 条件不带分区键（如按 user_id 查询但按 created_at 分区），MySQL 会扫描所有分区，I/O 和 CPU 开销反而更高。
实操建议：
- 分区键必须是高频查询条件的列，且该列区分度要高（避免单个分区过大）。时间类字段（
DATE/DATETIME）最常用，但需配合TO_DAYS()或YEAR()等函数，注意函数必须和WHERE中一致才能触发分区裁剪 - 用
EXPLAIN PARTITIONS SELECT ...验证是否命中分区。输出中partitions列只显示实际访问的分区名才算有效 - 不要为小表（如
切换后必须验证外键和应用连接
重命名表后，原表上的外键约束不会自动迁移，且应用若缓存了表元数据（如某些 ORM 的 schema cache），可能继续往旧表写数据。
实操建议：
- 检查外键：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 't1_old';，手动在新表上重建外键（注意级联行为） - 重启应用或清空 ORM 的表结构缓存（如 Django 的
django.db.models.base.Model._meta缓存） - 上线后立即查
INFORMATION_SCHEMA.PARTITIONS确认分区数量，并用SELECT COUNT(*) FROM t1 PARTITION(p2023);抽样验证数据分布
分区表重建不是一键操作，真正耗时的是索引重建和数据迁移。别省略 RENAME 前的读写隔离步骤，也别假设 EXPLAIN 显示“Using where”就代表分区生效——必须看 partitions 字段。
