RENAME TABLE批量迁移仅适用于无外键/视图/存储过程的简单库；它原子性强、速度快，但不迁移依赖对象，需提前检查并清理外键、视图、存储过程等拦路虎，且新库须显式匹配原库字符集与排序规则。
RENAME TABLE 批量迁移表是可行路径，但仅限于无外键/视图/存储过程的简单库
直接 RENAME TABLE old_db.tbl1 TO new_db.tbl1 是 MySQL 唯一支持的“逻辑层重命名”操作，它不碰文件系统，原子性强，速度快。但它只搬表，不搬依赖对象——一旦原库含外键、触发器、视图或存储过程，这条路立刻失效。
- 外键约束里的
REFERENCES old_db.other_table不会自动更新，后续 INSERT/UPDATE 会报ERROR 1824 - 视图定义里硬编码的
FROM old_db.tbl1会变无效，SELECT * FROM v1直接报ERROR 1146 -
mysqldump --routines --triggers导出的内容不会被RENAME TABLE带走，新库查不到过程或事件
执行前必须手动检查并清理依赖关系
盲目执行 RENAME TABLE 很容易让新库处于“能连上、查不了、写不进”的半瘫痪状态。先确认有没有拦路虎：
- 查外键：
SELECT CONSTRAINT_NAME, TABLE_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'old_db' AND REFERENCED_TABLE_SCHEMA = 'old_db'; - 查视图：
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'old_db'; - 查存储过程/函数：
SELECT NAME, TYPE FROM mysql.proc WHERE DB = 'old_db';（注意：MySQL 8.0+ 已弃用mysql.proc，改用INFORMATION_SCHEMA.ROUTINES）
有结果就别走这条线——要么删掉这些对象再操作，要么切回 mysqldump 方案。
脚本化批量 RENAME 需注意权限与锁行为
用 shell 或 Python 拼 RENAME TABLE 语句本身没问题，但两个细节常被忽略：
- 执行用户必须对
old_db和new_db都有ALTER+DROP+CREATE权限，缺一不可；否则卡在某张表就停住 - InnoDB 表重命名会持表级排他锁（
EXCLUSIVEMDL），期间所有对该表的读写都被阻塞；高并发下易引发连接堆积，wait_timeout超时断连 - 命令行中不能跨库写
RENAME TABLE old_db.t1 TO new_db.t1, old_db.t2 TO new_db.t2—— MySQL 要求所有源表在同一库，目标库也必须统一，否则语法报错ERROR 1103
字符集和排序规则不会自动继承，必须显式创建新库
CREATE DATABASE new_db 如果不带 CHARACTER SET 和 COLLATE，会按 MySQL 实例默认值建库（通常是 utf8mb4 + utf8mb4_0900_ai_ci），但旧库可能是 latin1 或 utf8mb4_unicode_ci。一旦不一致，导入后中文乱码、ORDER BY 结果异常、唯一索引冲突都可能发生。
务必先查原库定义：SHOW CREATE DATABASE old_db;，再照抄建库语句，例如：
CREATE DATABASE new_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
漏掉这步，后续修复成本远高于重做一次。
真正安全的重命名，从来不是“怎么快”，而是“哪些东西不能丢”。表名只是表皮，外键、视图、字符集、权限才是数据库活着的筋骨——它们不跟着 RENAME TABLE 走，就得你一条条盯住。
