MySQL重命名表应优先使用RENAME TABLE，因其是原子操作且安全；ALTER TABLE RENAME存在隐式拷贝风险。需检查硬编码表名、视图依赖及外键约束，并注意大小写、存储引擎和客户端缓存问题。
MySQL 重命名表用 RENAME TABLE，不是 ALTER TABLE ... RENAME
MySQL 支持两种语法重命名表，但行为和兼容性不同。RENAME TABLE 是标准、安全、原子的操作；而 ALTER TABLE old_name RENAME TO new_name 在某些旧版本或存储引擎下可能触发隐式拷贝，风险更高。线上环境务必优先用 RENAME TABLE。
-
RENAME TABLE是原子操作，失败则回滚，不会留下中间状态 - 不支持跨数据库重命名（如从
db1.t1到db2.t2）需加库名前缀，且目标库必须存在 - 若表被锁（如长事务持有 MDL 锁），
RENAME TABLE会阻塞，直到锁释放 - 示例：
RENAME TABLE user_info TO user_profile;
重命名前必须检查的三件事
直接执行 RENAME TABLE 不报错，不代表业务能继续跑。很多问题在 rename 后才暴露。
- 确认所有 SQL 中硬编码的表名已同步更新：包括应用代码、定时脚本、视图定义、存储过程里的
FROM或JOIN子句 - 检查视图是否依赖该表：
SELECT * FROM information_schema.VIEWS WHERE VIEW_DEFINITION LIKE '%old_table_name%'; - 确认外键约束 —— 如果该表是其他表的外键引用目标，重命名后外键仍指向原名，但表已不存在，下次插入/更新会报
ERROR 1452 (HY000)
遇到 ERROR 1017 (HY000): Can't find file 怎么办
这个错误通常不是权限或路径问题，而是表名大小写或存储引擎不匹配导致的。Linux 下 MySQL 默认区分表名大小写（由 lower_case_table_names 配置决定），而 Windows 不区分。
- 先查实际表名：
SHOW TABLES LIKE 'user%';，注意输出是否为user_Info而非user_info - 如果原表是 MyISAM，重命名后 InnoDB 表无法继承其 .frm 文件结构，可能引发元数据不一致
- 不要手动改磁盘文件名（如
mv user_info.frm user_profile.frm），MySQL 不认这种操作，后续SHOW CREATE TABLE会报错
rename 后应用连不上表？重点看字符集和连接器缓存
表名改了，但应用层报 “Table doesn’t exist”，大概率不是 SQL 写错，而是客户端或连接池缓存了旧的表元数据。
- Java 应用用 HikariCP + MySQL Connector/J 8.0+：需设置
cachePrepStmts=false或升级到 8.0.33+，否则预编译语句缓存可能保留旧表名 - PHP 的 PDO 默认不缓存表结构，但若用了
mysqlnd的查询缓存（已废弃），需重启 PHP-FPM 清除 - MySQL 自身的表定义缓存（
table_definition_cache）不影响 rename，但极端高并发下可能有毫秒级延迟，无需干预
重命名本身很快，真正耗时的是验证上下游是否适配——尤其是那些没进 Git、藏在 crontab 或 DBA 手动维护的 SQL 里。别信“只改一个地方”，先搜全量代码和 SQL 日志。
