rename table 不支持跨库重命名，蓝绿切换必须在同一数据库内完成；需先建好绿表（如 users_v2），再原子交换 users ↔ users_v2，全程毫秒级、无中间态、支持回滚。
RENAME TABLE 本身不支持跨库重命名，蓝绿切换必须在同一数据库内完成
MySQL 的 RENAME TABLE 是原子操作，执行瞬间完成（毫秒级），但前提是源表和目标表必须位于同一数据库。如果你试图用 RENAME TABLE db1.tbl TO db2.tbl 实现跨库切换，会直接报错：ERROR 1049 (42000): Unknown database 'db2' 或更常见的 ERROR 1146 (42S02): Table 'db2.tbl' doesn't exist —— 因为语法只允许同库内重命名，且目标表名不能已存在。
所以真正的蓝绿切换路径是：先在同库中准备好「绿表」（比如 users_v2），确保数据一致、索引就绪、应用已适配；再用 RENAME TABLE 原子交换 users ↔ users_v2。整个过程对客户端透明，无锁等待，真正“秒级”。
- 不要提前删旧表，
RENAME TABLE要求目标名不存在，但旧表可保留用于回滚 - 若用
RENAME TABLE users TO users_bak, users_v2 TO users一行执行，是原子的：要么全成功，要么全失败，不会出现中间态 - 注意权限：执行用户需对原表和新表都拥有
ALTER和DROP权限（因为重命名隐式包含 DROP + CREATE）
RENAME TABLE 会阻塞 DML，但窗口极短，需避开业务高峰
虽然 RENAME TABLE 本身很快，但它需要获取两个表的 metadata lock (MDL)，期间会阻塞新的 SELECT、INSERT、UPDATE、DELETE，直到锁释放。如果此时有长事务正在访问其中任一表，RENAME 会被挂起，而后续所有新请求也会排队等待 MDL，造成雪崩式延迟。
- 执行前务必检查：
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_INFO LIKE '%users%';，重点看PROCESSLIST_STATE = 'Waiting for table metadata lock' - 线上建议搭配
SET lock_wait_timeout = 2;（单位秒），让超时语句快速失败，避免卡死 - 真实耗时通常 RENAME 慢，而是你在等别人释放锁
蓝绿切换后应用连接池可能缓存旧表结构，需主动刷新
很多 Java 应用（如用 HikariCP + MyBatis）会在启动时预加载表元数据，或在首次查询时缓存 ResultSetMetaData。切换后即使表名已变，连接池里已有连接仍可能沿用旧列定义，导致 Column 'xxx' not found 或字段顺序错乱。
- 不是 MySQL 的问题，是客户端行为：连接复用时 JDBC 驱动不会自动重查
DESCRIBE - 解决方案分三级：① 切换前让应用下线部分实例（滚动）；② 切换后调用
HikariCP的evictConnections()清空连接池；③ 最稳妥是重启应用实例，确保全新建连 - 验证方式：切完立刻执行
SELECT COUNT(*) FROM users;+DESCRIBE users;，确认返回的是新表结构
无法回滚到“正在写入”的旧表，备份和校验必须前置
RENAME TABLE 是不可逆的操作（没有 UNDO RENAME），一旦执行，原表名就指向新数据。如果你没提前把旧表另存为 users_bak，或者没校验绿表数据完整性，出问题只能从备份恢复，耗时远超“秒级”。
- 标准流程必须含三步：①
CREATE TABLE users_v2 LIKE users;+INSERT INTO users_v2 SELECT * FROM users;（或用 pt-archiver 同步）；② 全量校验（推荐pt-table-checksum）；③RENAME TABLE users TO users_bak, users_v2 TO users; - 别依赖
FLASHBACK：MySQL 官方不提供 DDL 闪回，binlog 只能恢复 DML，且RENAME在 binlog 中记为Query_log_event，无法自动反向生成还原语句 - 最易忽略的一点：切换后旧表
users_bak仍在写入吗？如果应用双写或灰度未关干净，它可能持续被更新，导致你误以为“回滚安全”，实则数据已分裂
