能接近零停机——RENAME TABLE本身是原子操作、毫秒级完成，但需确保长事务已结束、应用写流量已切走、无FOR UPDATE等依赖旧表的活跃语句，再配合LOCK TABLES与原子切换流程，方可实现秒级停机。
RENAME TABLE 能否真正实现零停机？
不能，但可以接近零停机——RENAME TABLE 本身是原子操作、毫秒级完成，但“零停机”取决于你如何组织上下游依赖。关键不是命令本身，而是切换前后的应用状态和事务边界是否可控。
切换前必须确保的三件事
跳过这三步，哪怕 RENAME TABLE 执行再快，应用也会报错或读写旧表。
- 所有正在运行的事务（尤其是长事务）已提交或回滚，否则可能因表名变更导致
ERROR 1100 (HY000): Table 'xxx' was not locked with LOCK TABLES或隐式锁等待 - 应用层已停止对旧表的写入（比如关闭写流量、切走消息队列消费者、暂停定时任务），仅允许读——注意：ORM 缓存、连接池中的预编译语句仍可能引用旧表名
- 确认没有活跃的
SELECT ... FOR UPDATE或INSERT ... SELECT正在引用待切换的表，这类语句在重命名时会直接失败
典型安全切换流程（含事务与连接处理）
以把 orders_new 切为 orders 为例，核心是“先让新表就绪，再原子替换，最后清理”：
START TRANSACTION; -- 1. 锁定两张表（防止重命名期间有新 DML 干扰） LOCK TABLES orders WRITE, orders_new WRITE; -- 2. 确保 orders_new 数据已同步完成（如通过 INSERT ... SELECT 或 pt-online-schema-change 同步） -- 3. 原子切换 RENAME TABLE orders TO orders_old, orders_new TO orders; -- 4. 立即释放锁（不要在事务里 COMMIT，LOCK TABLES 不受事务控制） UNLOCK TABLES;
注意：LOCK TABLES 是会话级阻塞，需在单独连接中执行；生产环境建议配合 SELECT CONNECTION_ID() 和 KILL 清掉残留连接，避免连接池复用旧连接继续写 orders_old。
容易被忽略的兼容性陷阱
RENAME TABLE 看似简单，但这些细节常导致上线后出问题：
- 触发器、视图、存储过程里硬编码了旧表名，重命名后它们不会自动更新，调用时直接报
ERROR 1146 (42S02): Table 'db.orders' doesn't exist - MySQL 5.7+ 支持跨库重命名（
RENAME TABLE db1.t1 TO db2.t1），但目标库必须存在，且用户需同时拥有两个库的ALTER和DROP权限 - 如果表启用了
ROW_FORMAT=COMPRESSED或使用了加密表空间，重命名后表属性不变，但某些备份工具（如 mydumper）可能因元数据缓存未刷新而漏备新表 - Percona XtraDB Cluster 或 Group Replication 环境下，
RENAME TABLE是 DDL，会触发全集群同步，需确认集群状态稳定，避免在主节点切换时从节点延迟突增
真正的难点不在那条 RENAME TABLE 命令，而在它前后 5 秒内你是否掌控了所有连接、缓存、依赖对象的状态。
