navicat 16 同步日志不显示详细错误行号，因其直接透传数据库服务端基于字符偏移量（而非源文件行号）的原始错误提示；mysql/postgresql 在批量执行时仅报“near 'xxx'”或“position n”，navicat 不解析 sql 也不映射行号，故无法生成行号。
navicat 16 同步日志不显示详细错误行号，是因为它本身不解析 sql 语句、不重写错误信息，所有报错都直接透传数据库服务端返回的原始提示——而 mysql/postgresql 等数据库在执行批量脚本时，通常只报“near 'xxx'”或“syntax error at position n”，并不标注真实行号。
数据库服务端根本没提供行号，Navicat 无法凭空生成
MySQL 的 ERROR 1064 (42000)、PostgreSQL 的 syntax error at or near "group" 这类错误，是服务端 parser 在语法树构建阶段抛出的，它基于字符偏移量（position）而非源文件行号。Navicat 拿到的就是这个 position 值，它既不读取你原始 SQL 文件的换行符，也不做行号映射，所以日志里只有“near 'xxx'”，没有第几行。
- 你可以用
mysql -u user -p db -e "source /path/to/script.sql"复现，错误输出同样无行号 - 若 SQL 文件含大量注释或长字符串，position 对应的实际位置可能跳转到几十行之外
- Navicat 的“执行当前查询”（Ctrl+R）对单条语句有效，但“运行 SQL 文件”（Ctrl+Shift+R）会把整个文件当一个块提交，服务端失去行边界上下文
分段执行 + SHOW CREATE TABLE 是最准的定位方式
面对几百行同步脚本，靠错误提示里的 “near 'GROUP'” 往前翻 10 行往往找不到真因——前面缺个括号或引号，会让 parser 直接崩在 GROUP 关键字上。必须主动切片验证：
- 把 SQL 文件按
;拆成独立语句，逐条粘贴进 Navicat 查询窗口执行（注意：有些语句末尾不能有分号，如DELIMITER $$块） - 若报错指向某张表（如
table_name），立刻在目标库执行SHOW CREATE TABLE `table_name`，对比源库输出，看是否缺失PARTITION BY、CHECK或字段类型不一致 - 对分区表、带函数的 CHECK 约束、含反引号的表名（如
`user-log`），Navicat 结构同步常静默丢内容，错误却报在后续 INSERT 上，误导性极强
SET SESSION sql_mode = 'STRICT_TRANS_TABLES' 能让错误提前暴露
MySQL 默认模式下，某些语法缺陷（如 GROUP BY 字段缺失、INSERT 少列）可能被容忍，直到数据写入才报错，此时行号更难追溯。开启严格模式后，parser 会在解析阶段就中断并给出更靠近问题源头的提示：
- 在 Navicat 查询窗口中先执行：
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'; - 再运行同步脚本——错误大概率提前出现，且
near位置更可信 - 注意：
ONLY_FULL_GROUP_BY触发的报错不是语法错误，而是语义检查，别误当成 SQL 写错
真正卡住人的从来不是“看不到行号”，而是把数据库服务端的 position 提示当成行号去数；实际要做的，是放弃依赖行号，改用分段执行、元数据比对和严格模式三板斧交叉验证——这才是同步脚本出错时最快落地的排查路径。
