Navicat导出的HTML差异报告不算审计报告，因其仅展示静态结构比对结果，缺失变更发起人、审批单号、时间戳、执行前校验语句、人工复核标记及数字签名等审计核心要素，无法满足等保/ISO27001对证据完整性与可追溯性的要求。
Navicat 本身不生成“符合审计要求”的发布报告，它只能输出结构差异快照（HTML）或同步脚本（SQL），而审计所需的可追溯、带签名、含上下文的正式报告，必须靠你补全元信息、归档路径和执行验证环节。
导出的 HTML 差异报告为什么不算审计报告
Navicat 的 Export as HTML 仅展示两张库之间「表是否存在」「字段类型是否一致」这类静态比对结果，但它缺失审计核心要素：
- 没有变更发起人、审批单号、上线时间戳（仅靠文件名
report_%Y%m%d_%H%i.html不足以证明时效性） - 不记录执行前的校验语句（例如
SELECT COUNT(*) FROM orders WHERE status = 'pending'），无法佐证数据一致性 - 不包含人工复核标记——审计关注的是“谁在何时确认了这个变更”，而非机器自动生成的内容
- HTML 文件本地打开易被篡改，且无哈希值或数字签名，不符合等保/ISO27001 对证据完整性的要求
真正能进审计归档的报告长什么样
一份可接受的发布报告应是 ZIP 包，内含以下 4 个不可分割的部分：
-
baseline_20260901_v2.3.sql：发布前从生产库导出的完整结构快照（用 Navicat「转储 SQL 文件」→ 勾选Structure only+Drop tables） -
diff_report_20260907.html：Navicat 结构比对后导出的 HTML（务必勾选Include detailed differences） -
verify_queries.sql：人工编写的 3–5 条关键校验 SQL，比如SELECT COUNT(*) FROM user_log WHERE created_at > '2026-09-07 10:00:00'，附执行结果截图 -
release_meta.json：纯文本元数据，含"release_id": "REL-20260907-001"、"approver": "DBA-Li"、"md5_of_baseline": "a1b2c3..."
Navicat 操作中三个关键避坑点
很多人卡在最后一步不是因为不会点导出，而是细节失控：
-
Save as SQL File导出的同步脚本默认不含SET FOREIGN_KEY_CHECKS=0，直接执行可能因外键约束失败；需手动在顶部添加，或用「Synchronize to Database」→ 第三步预览时勾选Disable foreign key checks - 对比时若目标库连接用的是
root@localhost，而实际发布用的是deployer@10.10.1.5，HTML 报告里的「Target」名称会误导审计员——务必右键差异行 →Properties核对 host/user 是否与发布凭证一致 - Navicat 17.3+ 对 MySQL 8.0 的 generated column 或 invisible index 识别不稳定，可能标为
different却在 HTML 中显示N/A；遇到这类字段，必须手工执行SHOW CREATE TABLE并截图附入verify_queries.sql的附件目录
最常被忽略的，是把 baseline_*.sql 和 diff_report_*.html 存在不同目录下，导致审计时无法交叉验证。所有文件必须同级存放、统一命名前缀、用 ZIP 打包——否则所谓“可追溯”，就只剩一纸空谈。
