RENAME TABLE 无法优雅完成大表切换，因其需同时获取原表和新表的元数据写锁，易被长事务阻塞；必须提前清理长事务、检查外键/视图/应用层依赖，并设置 lock_wait_timeout=1 秒超时防护。
不能靠 RENAME TABLE 直接“优雅”完成——它会卡住写，哪怕只是毫秒级，也足以在高并发下引发雪崩。 真正可行的路径是：用原子重命名做最终切换，但把锁等待控制在 1 秒内，并提前切断所有长事务和隐式依赖。
为什么 RENAME TABLE 在大表上不是“无感”的
它不拷数据、不改行格式，执行本身确实毫秒级。但问题出在元数据锁（MDL）：必须同时对原表名和新表名加写锁。只要有一个未提交事务正在查 old_table，RENAME TABLE 就会挂起等待，而不是失败。你看到的“慢”，其实是被别的事务拖住的。
- 常见现象：
Lock wait timeout exceeded、SHOW PROCESSLIST里一堆Waiting for table metadata lock - 锁等待时长 = 当前最长未提交事务的运行时间，跟表大小无关
- 即使只读流量大，只要存在长事务（比如一个没提交的
SELECT ... FOR UPDATE），就可能卡住
执行前必须验证的三类依赖
漏掉任何一类，重命名后服务就会报 ERROR 1146 或 ERROR 1824，且恢复成本远高于预防。
- 外键引用：查
information_schema.KEY_COLUMN_USAGE中REFERENCED_TABLE_NAME = 'old_table'的记录，对应表要先删外键，重命名后再重建 - 视图定义：用
SELECT VIEW_DEFINITION FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_table%'找出硬编码旧表名的视图，后续需ALTER VIEW更新 - 应用层缓存或配置：比如 MyBatis 的
mapper.xml、Spring JPA 的@Table(name = "old_table")，这些不会被数据库感知，必须人工核对
安全执行的实操要点（含超时防护）
目标不是“一次成功”，而是“失败可退、影响可控”。关键动作必须按顺序做：
- 低峰期执行：
SET SESSION lock_wait_timeout = 1;（单位秒），再跑RENAME TABLE mydb.old_table TO mydb.new_table;。超时就退出，不重试 - 提前清理长事务：执行前查
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5;，干掉运行超 30 秒的事务 - 跨库重命名必须显式带库名：
RENAME TABLE old_db.t1 TO new_db.t1;，省略库名直接报ERROR 1064 - 批量重命名务必用单条语句：
RENAME TABLE t1 TO t1_bak, t2 TO t2_bak, t3 TO t3_bak;，避免多条ALTER TABLE ... RENAME TO（语法非法）或分步执行导致状态不一致
真正容易被忽略的是权限与大小写敏感
MySQL 8.0 默认 lower_case_table_names = 0（Linux 下大小写敏感）。如果开发环境设为 1，而生产是 0，RENAME TABLE user_info TO User_Info 会找不到原表，直接报 ERROR 1146。另外，跨库重命名要求用户对两个库都有 ALTER 和 DROP 权限——不是只读权限够用。
