最可靠的做法是用Navicat结构同步功能直接比对源库与目标库结构，而非依赖开发提交的SQL文件；需重点核对DDL差异面板中的隐式变更、字段顺序、字符集、COMMENT等，并人工验证数据兼容性，审核通过后须经Git提交和CI/DBA执行，禁止直连生产库操作。
直接比对源库与目标库结构，不依赖开发提交的SQL文件
Navicat 本身不解析、不校验你收到的 001_add_phone_to_users.sql 文件是否真能安全执行，也不检查它和当前库结构是否一致。所谓“审核”，本质是验证「这份 DDL 在目标环境执行后，是否真能达到预期结构」。最可靠的做法是跳过 SQL 文件，用 Navicat 的结构同步功能，把开发库设为源、目标库（如测试库）设为目标，直接比对——绿色加号/红色减号才是真实差异，不是开发说“我加了字段”，你就信。
重点核对 DDL 差异面板里的隐式变更
结构同步窗口点开每条差异 → 点“DDL 比较”标签页，这里显示 Navicat 自动生成的变更语句。容易被忽略的关键点：
- MySQL 中
TINYINT(1)和BOOLEAN被当成不同类型：旧版 Navicat 会误标为不一致，需提前在Options > Compare settings勾选Ignore tinyint(1) vs boolean - 字段顺序变化默认触发“删+增”：勾选
Ignore column order避免误判 - 字符集或排序规则不一致（如
utf8mb4_0900_as_csvsutf8mb4_unicode_ci）不会标红，但可能影响索引行为，必须肉眼确认 -
COMMENT内容不同会被标记为差异，但通常不影响功能，可酌情忽略
执行前手动验证目标库数据兼容性
结构同步只管 DDL，不管数据。如果 DDL 包含字段类型收缩（如 VARCHAR(200) → VARCHAR(50)）或非空约束新增，必须人工查目标库实际数据：
- 查最大长度：
SELECT MAX(CHAR_LENGTH(phone)) FROM users; - 查空值占比：
SELECT COUNT(*) FILTER (WHERE phone IS NULL) * 100.0 / COUNT(*) FROM users; - 查非法字符（尤其从 Excel 导入后）：
SELECT phone FROM users WHERE phone !~ '^[0-9+\-\s()]*$';（PostgreSQL）或对应 MySQL 正则
这些结果决定你是直接执行、先清理数据，还是退回开发改方案。
审核完成≠批准上线，必须绑定部署流程
Navicat 的“执行”按钮只是执行 SQL，不是上线动作。架构师审核通过后，应要求开发将最终确认的 DDL 提交到 Git，并由 CI 流水线或 DBA 手动在目标环境执行——不能允许任何人用 Navicat 直连生产库点“执行”。同步窗口顶部显示的“将对 [目标库名] 应用以下更改”只是预览，不是授权凭证；真正的审批记录必须留在 Git PR 或工单系统里。
