Navicat执行SQL迁移脚本需手动操作：右键目标数据库→选“运行SQL文件”→加载本地migration_v2.1.0.sql→点击运行；务必提前备份，注意编码、分号分隔、超时设置及人工校验生成的结构同步SQL。
Navicat 里怎么执行 SQL 迁移脚本？
navicat 本身不提供“迁移脚本管理器”这类抽象层，它只是个 sql 客户端，所以所谓“管理迁移脚本”，本质是手动执行、校验、记录 sql 文件变更的过程。别指望它自动识别 up.sql / down.sql 或做版本回滚 —— 那得靠外部工具（如 flyway、liquibase）或人工约定。
实操上，最常用路径是：用 Navicat 打开目标数据库连接 → 右键选择“运行 SQL 文件” → 指向本地的 migration_v2.1.0.sql → 点击运行。注意：Navicat 默认以当前连接用户权限执行，不会模拟事务回滚（哪怕脚本里写了 START TRANSACTION），出错就停，不自动 rollback。
- 务必提前备份数据库，Navicat 不保存执行历史快照
- SQL 文件里避免使用分号以外的语句分隔符（如
/或空行），Navicat 解析能力有限，容易截断 - 如果脚本含多条
CREATE PROCEDURE或DELIMITER，直接运行会失败 —— 得先在查询窗口手动切到“命令行模式”（右键查询窗口 → “切换为命令行模式”），再粘贴执行
怎么对比两个环境的表结构差异并生成迁移 SQL？
这是 Navicat 最实用的迁移辅助功能，但容易被忽略细节：它生成的差异 SQL 是“单向覆盖式”的，不是幂等脚本。比如源库某字段是 VARCHAR(50)，目标库是 VARCHAR(100)，Navicat 默认生成 MODIFY COLUMN 改成 50，而不是判断大小后决定是否调整。
操作路径：连接源库和目标库 → 右键 → “结构同步” → 勾选要对比的表 → 下一步 → 在映射界面手动检查每项变更（尤其注意索引、外键、默认值是否被误删）→ 最后点击“生成 SQL”而非“执行”。生成的 SQL 必须人工审查，重点看：
-
DROP INDEX是否会破坏线上查询性能 -
ALTER TABLE ... CHANGE COLUMN在大数据表上是否锁表（MySQL 5.6+ 通常支持 ALGORITHM=INPLACE，但 Navicat 不提示） - 时间类型字段是否从
DATETIME被改成TIMESTAMP（时区行为不同）
为什么在 Navicat 里执行迁移脚本总卡住或报错？
常见现象是进度条不动、提示“Query execution was interrupted”，其实多数不是脚本问题，而是 Navicat 自身连接配置或服务端限制导致。
- 默认查询超时是 60 秒，大表
ALTER TABLE肯定超时 → 修改连接属性里的“查询超时（秒）”为 0（不限制） - MySQL 的
max_allowed_packet小于脚本体积 → Navicat 报错类似Packets larger than max_allowed_packet are not allowed→ 需在 MySQL 服务端调大该值，Navicat 侧无法绕过 - 脚本含中文注释或 BOM 头 → Navicat 读取时乱码，导致语法解析失败 → 用 VS Code 以 UTF-8 无 BOM 格式保存 SQL 文件
- Navicat 版本低于 15 对 PostgreSQL 的
JSONB操作支持不全，执行含@@@路径表达式的脚本会直接报错
能不能用 Navicat 自动追踪迁移版本？
不能。Navicat 没有内置 migration history 表或版本标记机制。有人试图用“查询收藏夹”存脚本、用“备注”字段写 v1.2.0，但这完全不可靠：无法验证执行状态、不能防重复执行、也不支持依赖顺序。
真要落地版本控制，必须配合外部手段：
- 在数据库里建一张
schema_version表，每次手动执行完脚本后，用 Navicat 插入一行记录（INSERT INTO schema_version (version, applied_at) VALUES ('v2.3.0', NOW())） - 把所有迁移脚本按命名规则放在 Git 仓库（如
001_init.sql、002_add_user_status.sql），用 Navicat 打开时按文件名顺序执行 - 对关键环境（如生产），禁用 Navicat 直连，改用 CI 流水线调用
mysql -h -u -p ，Navicat 仅用于开发/测试环境的手动验证
真正麻烦的从来不是执行动作，而是确保“谁在什么时候对哪个库执行了哪版脚本且结果可追溯”——Navicat 只管前半截，后半截得自己补。
