直接执行rename table是唯一安全可靠的方法——它仅修改元数据、原子性高、不触碰行数据；其他图形化方式（右键重命名、表界面改名等）均存在兼容性差、行为不可控或根本禁用等问题。
直接执行 rename table 是唯一不影响数据、且能保证原子性的方法——它不碰任何行数据，只改元数据，执行快、无风险。
为什么不能右键重命名表？
Navicat 12 及多数新版默认禁用对象栏右键 →「重命名」对表的操作：菜单项灰显或点击无响应。这不是你权限不够或操作错，而是 Navicat 故意屏蔽了该入口，因其底层未启用安全的元数据编辑模式。试图强行触发只会失败，不报错也不提示原因。
- 旧版（如 Navicat 5.7）支持按
F2改名，但仅限 MySQL 且依赖服务端配置（如lower_case_table_names），跨版本/跨数据库类型不可靠 - 设计表界面顶部修改表名字段 → 点「保存」看似可行，实则行为不一致：
MySQL会弹警告并组合执行RENAME TABLE+ALTER TABLE；PostgreSQL可能只提交字段变更而忽略表名；SQL Server该字段直接灰显不可编辑 - 所有这些“图形化路径”最终都封装成 SQL 执行，但错误时只报「执行失败」，不告诉你哪条语句卡住、是否部分生效
怎么安全执行 RENAME TABLE？
打开 Navicat 查询窗口，手写标准 SQL，这是最可控的方式：
- 基础语法：
RENAME TABLE `old_name` TO `new_name`;—— 必须用反引号包裹表名，尤其当含大小写、数字开头或特殊字符时（如`user_order_2024`） - 不能跨库重命名：
RENAME TABLE db1.t1 TO db2.t1会报错；如需迁移，得先建新库，再用ALTER TABLE db1.t1 RENAME TO db2.t1（MySQL）或导出导入 - 它是 DDL 原子操作：成功即生效，失败即回滚（但 MySQL 的
RENAME TABLE实际不支持事务回滚，所以执行前务必确认备份） - 执行后 Navicat 对象栏不会自动刷新，必须手动右键数据库 →「刷新」或按
F5
改完表名后哪些东西会断？
RENAME TABLE 只动表本身，所有依赖它的对象全失效，且 Navicat 完全不管：
- 外键约束仍指向旧表名，下次
INSERT/UPDATE会报错Cannot add or update a child row: a foreign key constraint fails - 视图定义里硬编码了旧表名，查询直接报
Table 'xxx.old_name' doesn't exist - 存储过程、函数、事件中若引用了旧表名，调用时崩溃
- 权限语句（如
GRANT SELECT ON old_name TO 'u'@'h'）不会自动同步，需手动用REVOKE+GRANT更新
这些必须人工检查 information_schema 或导出 DDL 后 grep，没有捷径。别指望 Navicat 提醒你——它连自己刚改过的表依赖关系都懒得扫描。
