Navicat显示的行数是MySQL对InnoDB表的估算值（INFORMATION_SCHEMA.TABLES.TABLE_ROWS），误差可达40%~50%，不随写入实时更新，且导出过程无锁、无一致性快照，期间源表并发写入导致基准与实际脱节；可靠校验必须用SELECT COUNT(*)。
Navicat 显示的行数根本不是真实 COUNT(*)
你看到的“导出结果共 12345 行”，大概率来自 information_schema.tables.table_rows，这是 mysql 对 innodb 表的采样估算值，官方明确说明误差可达 40%~50%。它不随 insert/delete 实时更新，analyze table 对它基本无效。跨平台（比如 windows 上用 navicat premium 16 查 linux 上的 mysql 5.7）只是放大了这个固有缺陷——不同客户端读到的都是同一份过期快照，但你误以为是“平台差异”。
导出过程本身没锁、没快照，源表还在写
Navicat 的「导出向导」默认不加锁，也不开启一致性快照（如 START TRANSACTION WITH CONSISTENT SNAPSHOT）。典型流程是：
- 开始导出前，先读一次
TABLE_ROWS或执行一次SELECT COUNT(*)（取决于设置）作为“预估总数” - 实际导出耗时几秒到几分钟，期间应用仍在往源表写入新数据
- 导出文件写完后，你再手动跑
SELECT COUNT(*)，发现比导出时显示的数字多/少几百行
这不是跨平台问题，而是并发写入导致基准和实际脱节。Mac 和 Windows 上的 Navicat 行为完全一致，都受 MySQL 服务端行为支配。
字符集或字段截断导致实际写入行数变少
导出为 CSV/Excel 时，若字段含特殊字符（如 emoji、
导出为 CSV/Excel 时，若字段含特殊字符（如 emoji、\0、换行符）或长度超限，Navicat 可能静默跳过整行，或截断后仍算作“一行”。常见诱因：
、换行符）或长度超限，Navicat 可能静默跳过整行，或截断后仍算作“一行”。常见诱因：
- 目标文件编码选错：比如导出含中文的 CSV 时勾选了
GBK，但数据库连接用的是utf8mb4，部分字符无法映射，触发丢行 -
max_allowed_packet过小：导出大字段（如 TEXT）时，MySQL 中途断开，Navicat 记录为“成功”但实际漏数据 - Excel 行数硬限制：Navicat 导出 Excel (.xlsx) 时，若单表超 1048576 行，会自动分 Sheet；但用户只看第一个 Sheet 就误判“数量不对”
真正可靠的验证方式只有手敲 SELECT COUNT(*)
别信右下角状态栏、别比两个 TABLE_ROWS、也别依赖 Navicat 导出完成后的“共导出 X 行”提示。必须：
- 导出前，在当前会话执行
SELECT COUNT(*) FROM your_table;，记下结果 - 导出过程中，确认源表无写入（停业务 or 执行
FLUSH TABLES WITH READ LOCK;） - 导出完成后，立刻对目标文件用脚本统计行数（
wc -l或 Excel 公式），并与上一步的COUNT(*)对比
跨平台本身不引入差异，但不同系统下容易忽略编码、权限、终端换行符（CRLF vs LF）等细节，这些才是实际影响导出完整性的点。
