MySQL不支持独立RENAME PARTITION命令，必须用ALTER TABLE表名RENAME PARTITION原名TO新名；仅主分区可重命名，子分区需REORGANIZE重建；分区名长≤64字符、禁用特殊符号、建议小写。
ALTER TABLE ... RENAME PARTITION 语法必须带表名
直接写 rename partition 会报错，mysql 不支持独立的分区重命名命令。你得通过 alter table 操作触发，且必须指定完整表名和原分区名。
- 错误写法：
RENAME PARTITION p2023 TO p2023_q4→ 报错ERROR 1064 (42000) - 正确写法：
ALTER TABLE orders RENAME PARTITION p2023 TO p2023_q4 - 只对
RANGE、LIST、HASH、KEY分区有效；LINEAR HASH和LINEAR KEY同样支持 - 重命名不改变分区定义（比如
VALUES LESS THAN值），只是改个名字，不影响数据分布或查询逻辑
子分区（SUBPARTITION）不能单独重命名
MySQL 不提供 RENAME SUBPARTITION 语法。所谓“重命名子分区”，本质是重建整个分区——先 DROP 原分区，再用新子分区名 ADD 回去。这会触发数据移动，不是轻量操作。
- 子分区名只是元数据标识，不影响访问路径；应用层查数据时从不引用子分区名，只走主分区名或查询条件下推
- 如果硬要改子分区名，得用：
ALTER TABLE logs REORGANIZE PARTITION p2024 INTO (PARTITION p2024 VALUES LESS THAN (2025) (SUBPARTITION sp_a_new, SUBPARTITION sp_b_new)) - 该操作会锁表（取决于 MySQL 版本和存储引擎），在大表上可能阻塞写入数秒到数分钟
重命名后，SHOW CREATE TABLE 显示新名但旧名仍可能残留
重命名成功后，SHOW CREATE TABLE 里分区名已更新，但某些场景下旧名还可能出现在错误信息或监控日志里——这不是 bug，是 MySQL 内部缓存或慢日志记录时机导致的视觉残留。
- 比如执行
SELECT * FROM orders PARTITION(p2023)后报错，错误信息里仍显示p2023，哪怕它已被重命名为p2023_q4 - 分区名变更不自动同步到已有查询计划缓存，但下次执行相同语句会重新解析，所以不影响功能
- 监控工具（如 Percona PMM）若硬编码抓取
INFORMATION_SCHEMA.PARTITIONS.PARTITION_NAME，需等下一个采集周期才刷新
分区名长度限制与特殊字符风险
分区名最大 64 字符，且不能含空格、点号、连字符（-）或反引号；下划线 _ 安全，数字开头也允许，但建议用字母开头更稳妥。
- 危险命名：
ALTER TABLE t RENAME PARTITION 2024-01 TO 2024_q1→ 报错ERROR 1064（因-被当减号解析） - 安全命名：
ALTER TABLE t RENAME PARTITION p2024_01 TO p2024_q1 - 名字过长不会截断，而是直接报错；超过 64 字符的
TO名称会触发ERROR 1059 (42000) - 大小写敏感性取决于系统变量
lower_case_table_names，但分区名本身不参与大小写转换，建议全程小写避免混淆
重命名分区看似简单，真正麻烦的是子分区没法原子修改，以及名字改完之后，那些没刷新的监控脚本、备份策略里的硬编码、甚至开发本地 SQL 注释里的旧分区名，都可能悄悄变成维护盲区。
