应只同步人工导出的纯文本 .sql 文件，禁用 .psc/.nsx/.ncx 等二进制格式；导出时须指定 utf8mb4 编码、包含 DEFINER、添加 DROP 语句；按 schema/data/migrations/queries 分目录管理；执行前校验目标库字符集与 sql_mode。
Navicat 保存的 SQL 文件本身可 Git 同步，但必须确保它们是人工导出的 .sql 文件，而非 .psc、.nsx 或 .ncx 等二进制/加密格式——后者 Git 无法 diff、不能合并、换机即失效。
只同步 .sql 文件，别碰 .psc 和 .nsx
Navicat 的 .psc（备份快照）、.nsx（同步任务）、.ncx（连接配置）全是加密或绑定本机环境的二进制文件。Git 虽能提交它们，但：
- diff 显示为 binary，看不出改了哪张表、哪个字段
- 多人协作时冲突无法手动合并，一覆盖就丢配置
- 换电脑后即使文件存在，
.psc会因 SSH 指纹、本地证书路径不匹配而直接打不开 -
.nsx在 macOS/Linux 下根本不能执行，Windows 上也依赖navigator.exe路径硬编码
真正该放进 Git 的，只有你用「导出向导」生成的纯文本 .sql 文件——它可读、可审、可重放，且自带注释说明来源和时间戳。
导出 SQL 时必须显式指定 utf8mb4 和 DEFINER
从 Navicat 导出 .sql 文件不是点一下就完事。漏掉关键参数，Git 同步过去在另一台机器上执行就会出错：
- 没勾选「导出为 UTF8MB4 编码」→ 中文字段变成
???，且 Git diff 看不出编码问题，只看到乱码字符 - 没启用「包含 DEFINER 子句」→ 还原视图或存储过程时报
Access denied; you need (at least one of) the SUPER privilege(s) - 没勾选「添加 DROP 语句」→ 多人反复导入同一份
.sql，表结构越积越多，主键冲突频发 - 导出命令底层实际调用的是：
mysqldump --default-character-set=utf8mb4 --routines --databases mydb > mydb_20260907.sql，这个参数组合才是安全基线
Git 仓库结构建议按环境+用途分目录
别把所有 .sql 文件全扔根目录。按用途组织，能快速定位、避免误执行：
-
/schema/：存放建库 + 建表 DDL，命名如create_db_utf8mb4.sql、init_users_table.sql -
/data/：只放小量初始化数据（如字典表），用INSERT ... VALUES，禁用大表mysqldump --tab输出的文本 -
/migrations/：按日期或版本号存增量变更，如v1.2.0_add_status_to_orders.sql，每份只做一件事 -
/queries/：临时分析脚本、报表 SQL，加-- [DESC] 统计昨日订单量注释头，方便团队理解
注意：/schema/ 和 /migrations/ 必须严格按顺序执行，Git 提交前用 mysql -u root mydb < schema/create_db_utf8mb4.sql 手动验证一次，比靠文档靠谱。
同步后执行前，先检查目标库的字符集和 SQL 模式
Git 把 .sql 文件拉过去了，不代表能直接跑通。常见静默失败原因：
- 目标 MySQL 实例的
character_set_database是utf8而非utf8mb4→ 即使文件里写了CHARSET=utf8mb4，建表仍用默认值，emoji 插入失败 - 目标库
sql_mode包含STRICT_TRANS_TABLES，而源库没有 →INSERT INTO t(a) VALUES('')在源库成功，在目标库报错 - Navicat 连接「高级」页里设的
Character set是utf8，但导出的.sql是utf8mb4→ 客户端解码错位，显示问号 - 执行前务必确认：
SHOW VARIABLES LIKE 'character_set%';和SELECT @@sql_mode;
最省事的做法：在 Git 仓库根目录放一个 check_env.sql，每次同步后先运行它，输出不一致项就停住，不让人凭感觉瞎试。
