RENAME TABLE 是原子操作，因其底层绑定文件系统 rename() 系统调用与 InnoDB 数据字典更新于同一事务；仅限同库同引擎，跨库或跨文件系统会退化为非原子复制流程。
RENAME TABLE 的原子性来自文件系统重命名 + 数据字典更新的绑定
MySQL 的 RENAME TABLE 是原子操作，根本原因不是“它被设计成原子”，而是它底层直接调用操作系统对表文件（如 .ibd）的 rename() 系统调用，并同步更新 InnoDB 数据字典 —— 这两个动作被封装在同一个事务中完成。只要存储引擎是 InnoDB、且操作在同一数据库内，就不存在“只改了文件名没更新元数据”或“只更新了字典没动文件”的中间态。
原子性只在特定条件下成立：同一库 + 同一存储引擎
跨库（如 db1.t1 TO db2.t1）或跨文件系统重命名时，MySQL 会退化为“复制 + 删除源”流程，此时不再原子：若中途失败，可能留下残留副本或源表丢失。InnoDB 表若放在裸设备或 NFS 上，也可能触发拷贝逻辑。所以判断是否原子，先看执行计划：SHOW PROCESSLIST 中如果看到 Copying to tmp table，说明已脱离原子路径。
- 必须使用
TO关键字，写成RENAME TABLE t1 AS t2会报错 - 目标表名必须不存在，否则整个语句直接失败，不会部分生效
- 涉及的表会被加独占元数据锁（
MDL_EXCLUSIVE），阻塞其他 DDL/DML，确保状态一致
为什么不能用 ALTER TABLE ... RENAME TO？
从 MySQL 8.0.33 开始，ALTER TABLE old_name RENAME TO new_name 已被彻底移除语法支持，执行即抛出 ERROR 1064。这不是兼容性问题，而是语义隔离：前者是独立 DDL 语句，天然支持多表、交换、跨库；后者曾是早期非标准扩展，缺乏事务边界控制，无法保证原子性。官方明确要求批量或关键 rename 必须走 RENAME TABLE。
-
RENAME TABLE t1 TO t2, t3 TO t4是单条语句，要么全成功，要么全失败 - 想交换两张表？直接
RENAME TABLE a TO tmp, b TO a, tmp TO b，三步压缩成一步 - 外键约束、视图、存储过程里的表名引用不会自动更新，得人工处理
容易忽略的“伪原子”陷阱
即使 RENAME TABLE 本身原子，整个业务逻辑未必原子。比如你重命名用户表后立刻查新表，但应用缓存还拿着旧名、连接池里有未清理的预编译语句、或者 binlog 复制延迟导致从库还没生效——这些都会造成“看起来不一致”。真正的安全边界只到语句执行完成那一刻，之后的依赖链要自己兜底。
最常被跳过的检查项是：重命名前确认没有活跃事务正在访问原表（SELECT * FROM performance_schema.events_statements_current WHERE SQL_TEXT LIKE '%old_table%'），否则会卡住锁，甚至引发超时中断。
