rename table 是唯一真正安全的方案，必须显式指定完整库名，跨库移动需目标库存在且有权限，外键依赖会硬性拦截执行，视图等对象会失效需手动修复，仅阻塞元数据锁不影响select，长事务会导致静默卡顿。
RENAME TABLE 是唯一真正安全的方案，其他方式（比如 ALTER TABLE ... RENAME TO 或 CREATE + DROP）在高并发业务表上都容易出问题。
必须用完整库名，不能省略 database.table
哪怕你已经执行过 USE mydb，RENAME TABLE users TO users_new 也会报错 ERROR 1064 (42000)。MySQL 要求显式写出库名：
RENAME TABLE mydb.users TO mydb.users_new;- 跨库移动也一样：
RENAME TABLE mydb.users TO otherdb.users;，前提是目标库otherdb存在且你有权限 - 批量生成语句时，务必从
information_schema.tables查，别手写——例如：SELECT CONCAT('RENAME TABLE ', table_schema, '.', table_name, ' TO ', table_schema, '.', REPLACE(table_name, 'old_', 'new_'), ';') FROM information_schema.tables WHERE table_schema = 'mydb' AND table_name LIKE 'old_%';
外键和视图会直接失败，不是“失效”而是阻断执行
如果表被其他表用外键引用，RENAME TABLE 会立刻报错 ERROR 1025 (HY000) 或 ERROR 1826 (HY000)，根本不会进入重命名阶段。这不是事后才发现的问题，是硬性拦截：
- 先查依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'users' AND TABLE_SCHEMA = 'mydb'; - 逐个删外键：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id; - 重命名完再重建外键，注意约束名不能重复
- 视图、存储过程、触发器不报错但会失效，必须人工 grep 源码或查
information_schema.VIEWS后手动改
锁表现象真实存在，但只卡“元数据锁”，不是全表锁
RENAME TABLE 会获取原表和新表名的 MDL（metadata lock）写锁，期间所有对该表的 INSERT/UPDATE/DELETE/ALTER 都会被阻塞，但 SELECT 不受影响。真正危险的是长事务：
- 如果有未提交事务正在查
users表，RENAME TABLE会等它结束；如果那个事务卡了 5 分钟，你的重命名就卡 5 分钟 - 用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%RENAME%';看是否被挂起 - 低峰期执行只是降低概率，不是万能解——得提前 kill 掉可疑长事务，或协调业务方暂停写入
- 别在重命名前后紧挨着跑
DROP TABLE或CREATE TABLE，容易引发锁竞争
别信“先 ALTER TABLE ... RENAME TO 再批量拼”的说法
单条 ALTER TABLE users RENAME TO users_new 虽然语法合法，但批量操作时极易出错：
- 多条语句不是原子的：第一条成功、第二条失败，状态就残缺不全
- 容易漏表或写反方向，尤其带前缀替换时（比如把
log_202301→archive_202301，手写 12 条极易错位） - 报错
ERROR 1050 (42S01): Table 'xxx' already exists往往就是前一条已建好新表名，后一条又试图重命名到同名目标 - 真要批量，必须用一条
RENAME TABLE t1 TO t1_new, t2 TO t2_new, ...——这是 MySQL 唯一保证原子性的路径
实际操作中最容易被忽略的点是：外键报错发生在执行瞬间，而不是事后；而长事务导致的阻塞不会报错，只会安静卡住，直到超时或事务释放锁。这两类问题都不体现在日志里，得靠监控和预检兜底。
