会，RENAME TABLE 会卡住线上服务，因元数据锁（MDL）全表级阻塞所有DML和DDL操作，等待时长取决于最长未提交事务而非表大小。
RENAME TABLE 会卡住线上服务吗？
会，而且是元数据锁（MDL）全表级阻塞——不只是写操作，SELECT、INSERT、UPDATE、DELETE、ALTER 全部排队挂起，直到重命名完成。这不是慢，是强制等待。
关键点：锁等待时长取决于当前最长未提交事务，不是表大小。一张 200GB 的表，RENAME TABLE 本身毫秒级完成，但若有个 UPDATE 卡了 8 分钟没提交，你就得等满 8 分钟。
- 执行前务必查
SHOW PROCESSLIST，确认没有长时间运行或未提交的事务 - 用
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'db_name' AND OBJECT_NAME IN ('old_table', 'new_table');看是否有残留 MDL 占用 - 别信“大表才慢”的经验——小表在长事务下一样卡死
跨库重命名 or 同库重命名？权限和引擎怎么配？
语法支持 RENAME TABLE db1.t1 TO db2.t1，但这本质是“移动+重命名”，不是纯重命名。它要求：
- 你对
db1和db2都有DROP和CREATE权限（注意：不是ALTER） - InnoDB 表 MySQL 5.7+ 支持跨库；MyISAM 要求两个库在同一文件系统下，否则报
ERROR 1017 - 目标库必须存在，否则直接报
ERROR 1049 (42000): Unknown database - 如果目标库已有同名表，命令失败（安全设计，不覆盖）
特别注意：lower_case_table_names 设置差异极易翻车。MySQL 8.0 默认为 0（Linux 下大小写敏感），而开发环境常设为 1。RENAME TABLE UserTable TO usertable 在生产可能直接报 ERROR 1146。
外键、视图、存储过程会自动更新吗？
不会。重命名后，所有硬编码原表名的地方全部失效：
- 外键约束仍指向旧表名 → 后续
INSERT报ERROR 1824 - 视图查询直接报
ERROR 1146 - 存储过程、函数、触发器内 SQL 不会重编译，运行时报错
必须手动处理：
- 先查外键：
SELECT CONSTRAINT_NAME, TABLE_NAME, REFERENCED_TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'old_table'; - 删外键：
ALTER TABLE child_table DROP FOREIGN KEY fk_name; - 重命名后再重建：
ALTER TABLE child_table ADD CONSTRAINT ... REFERENCES new_table(...); - 查视图：
SELECT TABLE_NAME, VIEW_DEFINITION FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_table%';，然后CREATE OR REPLACE VIEW更新定义
如何控制锁等待时间并预留回退路径？
别依赖“快速完成”，要主动设超时、分阶段、留退路：
- 会话级设锁等待上限：
SET SESSION lock_wait_timeout = 3;（单位秒），再执行RENAME TABLE old TO new;。超时就失败，不硬扛 - 批量重命名必须用单条语句：
RENAME TABLE t1 TO t1_bak, t2 TO t2_bak;——原子性保障，避免手工拼错或漏表 - 操作后立刻验证：
SELECT COUNT(*) FROM new_table;（应有数据）、SELECT COUNT(*) FROM old_table;（应报错不存在）、SELECT ENGINE, ROW_FORMAT FROM information_schema.TABLES WHERE TABLE_NAME = 'new_table';（确认元数据一致） - 回退方案不是“再 rename 回去”——而是提前备份表结构：
SHOW CREATE TABLE old_table;，并确保mysqldump --no-data已就绪
真正容易被忽略的是权限映射：重命名不影响 mysql.user 表中基于库/表名的细粒度权限，应用连新表名可能因权限不足直接拒绝访问。
