MySQL批量改表名必须用RENAME TABLE，ALTER TABLE ... RENAME TO在8.0.33+已彻底移除；它支持原子性多表操作、跨库移动及表名交换，但需检查外键、视图、长事务等隐性依赖。
MySQL批量改表名只能用 RENAME TABLE，别碰 ALTER TABLE ... RENAME TO——8.0+ 版本直接报 ERROR 1064，不是语法糖问题，是彻底不支持。
为什么必须用 RENAME TABLE 而不是 ALTER TABLE RENAME
这不是“写法偏好”，而是硬性限制：ALTER TABLE old_name RENAME TO new_name 在 MySQL 8.0.33+、8.4 等主流版本中已移除语义支持，执行即报错。而 RENAME TABLE 是独立语句，天然支持原子性多表操作，且不涉及数据拷贝，毫秒级完成。
-
RENAME TABLE t1 TO t2, t3 TO t4是合法批量语法；ALTER TABLE t1 RENAME TO t2, t3 RENAME TO t4根本不被解析 - 跨库移动（如
db1.t1 TO db2.t1）也只认RENAME TABLE，且必须显式写全库名 - 想交换两张表名（比如上线新表），必须用三步临时命名：
RENAME TABLE real TO tmp, new TO real, tmp TO new，RENAME TABLE按从左到右顺序执行，不能省略中间步骤
如何安全生成批量重命名语句
手敲易错位、漏表、反向替换（比如把 log_202301 改成 old_log_202301 而非 new_log_202301）。正确做法是查 information_schema.tables 自动生成：
SELECT CONCAT('RENAME TABLE ', table_name, ' TO ', REPLACE(table_name, 'old_', 'new_'), ';')
FROM information_schema.tables
WHERE table_schema = 'mydb' AND table_name LIKE 'old_%';- 执行前务必人工核对输出：新表名是否已存在？是否和视图/外键里硬编码的名称冲突？
- 若会话启用了
SQL_SAFE_UPDATES，需先运行SET SQL_SAFE_UPDATES = 0，否则执行时报错 - 不要在从库上直接执行，除非你明确设置了
SET sql_log_bin = 0，否则可能引发主从延迟或复制中断
执行前必须检查的三个隐性依赖
RENAME TABLE 不报错，但会卡住、失败，或改完立刻业务出错——问题往往不在语句本身，而在外部依赖：
-
外键：如果其他表的外键引用了源表，
RENAME TABLE会直接报ERROR 1451。查依赖用：SELECT CONSTRAINT_SCHEMA, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'old_table'；要么删外键再重建，要么临时关检查（SET FOREIGN_KEY_CHECKS = 0），但后者风险自担 -
视图：视图定义里的
FROM old_table不会自动更新，改名后查询直接报ERROR 1146。查视图依赖：SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_table%' -
长事务：哪怕只是个跑了 3 分钟的
UPDATE，RENAME TABLE就会卡在Waiting for table metadata lock状态。执行前先看：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5
跨库移动时权限和路径的硬约束
跨库不是“改名”，是物理移动，对环境更敏感：
- 用户必须同时拥有源库的
ALTER和DROP权限，以及目标库的CREATE和INSERT权限；缺一不可，报ERROR 1044时不会提示缺哪个 - 目标库必须已存在，否则报
ERROR 1049；目标表名必须不存在，否则报ERROR 1050 - 不支持跨文件系统移动（例如源库在
/var/lib/mysql/db1，目标库挂载在/mnt/ext/db2），失败时无明确错误，只卡住或锁超时
真正麻烦的从来不是语句怎么写，而是改完之后谁还在用旧名字——外键、视图、应用代码、定时任务脚本，都得同步扫一遍。漏掉一个，线上就可能报错。
