RENAME TABLE是唯一真正安全的在线重命名方式，因其原子性更新数据字典和文件系统指针、毫秒级完成，但会持写MDL锁阻塞所有DML/DDL及SELECT（MySQL 8.0+），且必须显式写全库名、不支持事务回滚、跨库需双库权限。
RENAME TABLE 是唯一真正安全的在线重命名方式
它不移动数据、不重建索引、不复制行，只是原子性地更新数据字典和文件系统指针（InnoDB 的 .ibd 文件名或数据字典项），毫秒级完成。但“在线”不等于“无感”——它会持有一个写类型的元数据锁（MDL），阻塞所有对原表名和新表名的 DML（INSERT/UPDATE/DELETE）、DDL（ALTER）甚至 SELECT（MySQL 8.0+ 默认行为）。SELECT 被阻塞这点常被误认为“只读不受影响”，实际并非如此。
- 必须显式写全库名：
RENAME TABLE mydb.orders TO mydb.orders_new;，哪怕已执行USE mydb，省略库名会报ERROR 1064 (42000) - 跨库重命名可行：
RENAME TABLE old_db.logs TO new_db.logs;，但要求你对两个库都有DROP和CREATE权限，且目标库存在 - 不支持事务回滚：一旦执行成功，无法用
ROLLBACK撤销；失败则整个语句回退（多表时全部不生效） - 大表小表耗时一致——锁等待时间取决于最长未提交事务，而非表大小。一个卡住 8 分钟的
UPDATE会让RENAME等满 8 分钟
为什么 ALTER TABLE ... RENAME TO 不适合线上大表
它本质是 RENAME TABLE 的语法糖，在 MySQL 内部仍走相同路径，但有更隐蔽的风险：
- 不支持批量：只能一次改一张表，脚本出错易导致部分重命名、状态不一致
- 容易漏权限：某些版本对
ALTER权限校验更松，但实际执行时仍需DROP，线上报错才发现权限不足 - 无法跨库：
ALTER TABLE old_db.t1 RENAME TO new_db.t1;直接语法错误（ERROR 1103），而RENAME TABLE明确支持 - 在低版本（如 MySQL 5.6）中，
ALTER TABLE ... RENAME TO对 InnoDB 表可能触发隐式COPY算法，导致锁表数小时——RENAME TABLE则永远是原子指针交换
执行前必须查清的三类依赖
外键、视图、存储过程/函数不会让 RENAME TABLE 报错，但会让后续业务直接失败。它们不是“失效”，而是“硬拦截”或“静默失效”：
- 外键：只要其他表用
FOREIGN KEY ... REFERENCES orders，RENAME TABLE orders TO orders_new就会立刻报ERROR 1025或ERROR 1826，根本不会执行。先查：SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'orders' AND TABLE_SCHEMA = 'mydb'; - 视图：不会报错，但
SELECT * FROM v_user_summary;若定义里含FROM orders，重命名后直接报ERROR 1146。查：SELECT TABLE_NAME, VIEW_DEFINITION FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%orders%'; - 存储过程/函数：MySQL 8.0+ 查
INFORMATION_SCHEMA.ROUTINES；若含硬编码表名，调用时才暴露问题。建议用mysqldump --routines导出后grep -n 'orders'
真正容易被忽略的锁与超时控制
别信“低峰期就安全”。长事务才是最大敌人。你看到的卡顿，90% 是在等一个没 COMMIT 的事务释放 MDL。
- 执行前确认无残留锁：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_DURATION, LOCK_STATUS FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'mydb' AND OBJECT_NAME IN ('orders', 'orders_new'); - 强制设置超时，避免无限等待：
SET SESSION lock_wait_timeout = 3;（单位秒），再跑RENAME TABLE。超时就失败，不硬扛 - 查可疑长事务：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE TIME > 60 AND COMMAND != 'Sleep';，必要时KILL - 别在重命名前后紧挨着跑
DROP TABLE或CREATE TABLE，这些操作也争抢 MDL，容易引发连锁排队
最危险的不是命令本身，而是你以为它“只是改个名字”——它动的是整个数据库的元数据契约。表名变了，所有引用它的 SQL、应用配置、监控脚本、备份策略都得同步，漏一项，故障就在下一秒。
