必须用 rename table 而非 alter table ... rename to，因后者在 mysql 8.0.33+ 已移除，且不支持原子批量操作；rename table 天然原子、全成功或全失败，并需校验目标库存在、新表名未占用、无外键/视图硬编码依赖。
直接用 RENAME TABLE 批量执行，别拆成多条 ALTER TABLE ... RENAME TO，否则极易出错、不原子、难回滚。
为什么必须用 RENAME TABLE 而不是 ALTER TABLE ... RENAME TO
MySQL 8.0.33+ 及主流生产版本中，ALTER TABLE old_name RENAME TO new_name 已被明确移除语法支持，执行即报 ERROR 1064 (42000)。即使在某些旧分支能跑通，它也是一次只能改一张表，批量写几十上百条容易漏逗号、错位、目标名重复——而 RENAME TABLE 天然支持原子性批量：RENAME TABLE t1 TO t1_new, t2 TO t2_new, ...，要么全成功，要么全失败，状态始终一致。
生成语句前必须检查三件事
人工拼 SQL 是高危操作，尤其表数过百时。务必先查 information_schema 自动构造，并验证以下三点：
- 目标库是否存在？跨库重命名时若
new_db不存在，会报ERROR 1049 (42000): Unknown database 'xxx'，不是权限问题 - 所有新表名是否真实未被占用？哪怕存在同名视图、临时表或已删除但未清日志的残留表，都会触发
ERROR 1050 (42S01): Table 'xxx' already exists - 是否有外键/视图硬编码旧表名？用这条查外键：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'old_table' AND REFERENCED_TABLE_SCHEMA = 'your_db'；查视图：SELECT TABLE_NAME FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'your_db'
安全执行的关键细节
生成好语句后，不能直接粘贴执行。注意这些实操卡点：
- 必须显式带上库名，哪怕刚
USE your_db过也不行：RENAME TABLE users TO users_new必报错；正确写法是RENAME TABLE your_db.users TO your_db.users_new - 如果会话启用了安全模式（
SQL_SAFE_UPDATES = 1），执行前得先SET SQL_SAFE_UPDATES = 0，否则报错中断 - 重命名期间会同时持有原表和新表的元数据锁（MDL），若有长事务正在读原表（比如一个跑了 3 分钟的
SELECT ... FOR UPDATE），RENAME TABLE会挂起等待，而不是失败——上线前务必查SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED DESC LIMIT 5 - 外键、视图、存储过程不会自动更新。安全做法是：提前删外键 → 执行
RENAME TABLE→ 检查依赖 → 重建外键；或临时关检查：SET FOREIGN_KEY_CHECKS = 0，但需自行确保逻辑一致性
跨库迁移数百张表的权限与顺序陷阱
跨库重命名不是“改名”，是物理移动，权限要求更严：
- 需要对源库有
ALTER和DROP权限，对目标库有CREATE和INSERT权限——缺一不可，否则卡在某张表就停住 - 所有源表必须在同一库，所有目标表必须指向同一目标库，否则报
ERROR 1103 (42000): Bad table name - 字符集和排序规则不会继承。目标库若没显式指定
CHARACTER SET和COLLATE，会按实例默认值建（如utf8mb4_0900_ai_ci），而旧库可能是latin1或utf8mb4_unicode_ci，后续中文乱码、ORDER BY结果异常
真正容易被忽略的是：重命名本身毫秒级完成，但锁等待可能长达数分钟；而外键和视图失效往往在应用重启后才暴露，不是执行完就完事。
