Navicat显示行数≠实际行数，因读取INFORMATION_SCHEMA.TABLES.TABLE_ROWS估算值，误差可达40%~50%，须用SELECT COUNT(*)验证；导入行数偏差主因是Excel空行、字段超长、编码不匹配或类型转换失败。
Navicat 显示行数 ≠ 实际行数，先别怀疑同步出错
navicat 左侧对象树或表属性里显示的“行数”，本质是读取 information_schema.tables.table_rows 字段——对 innodb 表来说，这只是一个采样估算值，官方明确说明误差可达 40%~50%，且不随 insert/delete 实时更新。你刚删了 100 行，它可能还显示旧数字；你刚插了 50 行，它可能压根没变。这不是 navicat 的 bug，是 mysql 对 innodb 的设计取舍。
所以第一步必须做：用 SELECT COUNT(*) FROM your_table; 手动查真实行数。别刷新表节点，那只是重读一次过期的 TABLE_ROWS。
导入 Excel 后行数偏少，重点查字段长度和空行
常见现象是 Navicat 显示“成功导入 1000 行”，但查表只有 982 行。问题往往藏在 Excel 文件本身或字段定义里：
- Excel 中存在“看似空白、实则含不可见字符（如换行符、零宽空格）”的整行，Navicat 会跳过整行而不报错
- 某列数据实际长度超过目标字段定义，比如 Excel 里有 62 个字符的地址，而数据库字段是
VARCHAR(50)，超出部分被静默截断，某些版本甚至直接丢弃整行 - 日期或数字列在 Excel 里是“文本格式”，Navicat 尝试转类型失败后跳过该行（尤其当首行是标题、后续数据类型混乱时）
解决方法：先用 Excel 删除所有空行（不是“清除内容”，而是真正选中行 → 右键 → “删除行”）；再导出为 CSV，用文本编辑器确认每行结尾是否干净；最后检查目标表字段长度是否 ≥ Excel 最长数据。
导入后行数偏多，大概率是 Excel 空行或编码污染
导入后比 Excel 多几行？典型原因是 Excel 里存在“隐藏空行”——你肉眼看不见，但 Navicat 把它当有效行处理了。这类空行常出现在 Excel 滚动到底部后继续按方向键还能移动的位置。
另一个隐蔽原因：Excel 文件保存时用了非 UTF-8 编码（如 GBK），而 Navicat 连接设置或目标库字符集是 utf8mb4，中文字段解析失败，导致某行被拆成多行或生成异常占位符，间接抬高计数。
验证方式：把 Excel 另存为 UTF-8 编码的 CSV，再用记事本打开，看末尾是否有大量空行或乱码；同时执行 SHOW CREATE TABLE your_table; 确认 CHARACTER SET 和 COLLATE 是否与 Navicat 连接设置一致。
用「数据对比」功能定位具体哪几行不一致
如果 COUNT(*) 确实对不上，下一步不是重导，而是用 Navicat 15+ 的真实数据比对能力：
- 路径：工具 → 数据对比 → 选源库/目标库 → 下一步 → 勾选「比较所有记录」（默认只比主键，会漏字段值差异）
- 若表无主键，Navicat 会全字段比对，速度慢且结果难读，建议先导出两表数据到 CSV，用
diff或 Excel 的条件格式人工标色 - 比对前务必确认：两边字符集一致（
utf8mb4优先）、时间字段时区统一（避免TIMESTAMP因时区转换被标为不同）、数值字段精度相同（如DECIMAL(10,2)vsDECIMAL(10,3)）
最易被忽略的一点：Navicat 的「数据同步预览」页只告诉你“将插入/更新/删除多少行”，但不会列出被 INSERT IGNORE 或主键冲突跳过的行——那些行的真实去向，得翻同步完成后的「信息日志」，搜索 Duplicate entry 才能看到。
