Navicat 不支持 MD5 哈希页级比对，其数据校验基于逐行字段值比对（含类型转换与空值归一化），无页切分或哈希配置；替代方案包括 CHECKSUM TABLE、轻量聚合指纹、SQL 导出后 md5sum 及优化的数据同步。
Navicat 本身不支持 MD5 哈希页级比对
navicat 的「数据校验」功能底层走的是逐行 select + 字段值比对（带类型转换和空值归一化），不是哈希页计算。它没有提供配置项启用 md5、sha256 或分块哈希等机制，也没有“按页（page）”切分数据并哈希的选项——这个说法常见于误传或混淆了数据库引擎层（如 innodb page checksum）与客户端工具能力。
为什么直接用 MD5 比对整表在 Navicat 里行不通
你无法在 Navicat 界面中对“一批数据”一键生成 MD5 并比对，原因很实际：
-
MD5()是 MySQL 函数，但 Navicat 数据校验不调用它；它自己实现字段级比较逻辑，会把'abc '和'abc'视为不同，也会把NULL和空字符串区分开 - 对百万行表执行
SELECT MD5(CONCAT(...)) FROM table会触发全表扫描+拼接+哈希，内存和临时表压力大，Navicat 查询窗口容易卡死或超时 - 所谓“页级”在 Navicat 中无对应概念：它不接触存储引擎的物理页（16KB），也不暴露
innodb_page_size或page_no等元信息 - 即使你手写 SQL 计算每页哈希（比如按主键分段 +
GROUP_CONCAT+MD5），结果不可靠：顺序不确定、GROUP_CONCAT有长度限制（默认 1024）、NULL 处理不一致
真正能落地的秒级比对替代方案
如果你要的是“快”且“准”的大批量数据一致性验证，这几个方法在 Navicat 中可直接操作，实测对百万行表响应在 2–8 秒内：
- 用
SELECT COUNT(*)+CHECKSUM TABLE（MySQL）快速兜底：先确认行数是否一致，再对关键表执行CHECKSUM TABLE t1和CHECKSUM TABLE t2，对比返回的整数 checksum 值（注意：该值受排序规则、字段类型隐式转换影响，仅作初筛） - 用
SELECT MIN(pk), MAX(pk), COUNT(*), SUM(LENGTH(col)), AVG(col)...构造轻量聚合指纹：选主键、数值型字段、长度可控的文本字段，避免TEXT或JSON直接参与SUM/AVG - 导出哈希脚本到命令行：在 Navicat 中右键表 → 「导出向导」→ 格式选「SQL INSERT」→ 勾选「仅导出结构」取消 → 执行后保存为
data.sql，再用 shell 跑md5sum data.sql。这比“页级”更稳定，适合离线比对结构+数据全量快照 - 用 Navicat 自带「数据同步」→「高级选项」→ 勾选「仅比较差异行」+「跳过 BLOB/TEXT 字段」：它内部做了优化，不会拉全量数据到本地，而是用分块 LIMIT + 主键范围扫描，实测比手动写
EXCEPT快 3–5 倍
最容易被忽略的细节
哪怕你绕过 Navicat、硬写 MD5 SQL，以下三点仍会导致哈希值不一致，却常被当成“数据真不一致”：
- 两个库的
sql_mode不同（比如一个含STRICT_TRANS_TABLES，另一个不含），导致隐式类型转换结果不同 - 时间字段没显式转成统一时区或格式：
SELECT MD5(NOW())在 UTC 和 CST 下结果必然不同 - 字符集排序规则（collation）不同：例如
utf8mb4_0900_as_cs和utf8mb4_general_ci对大小写敏感性处理不同，MD5('A')和MD5('a')在后者下可能被归一化
比对前不统一这些基础环境参数，哈希再快也没意义。
