navicat报“语法错误”实为数据库服务端返回error 1064，真实错误点常在报错行号前几行，需用vs code语法高亮、全局搜索引号内关键词、删减复杂表达式定位，并通过命令行直连验证排除navicat环境干扰。
navicat 本身不解析 sql，报“语法错误”= 数据库服务端返回了 error 1064 或类似提示，问题一定在 sql 语句本身或执行环境，不是编辑器 bug。
看错在哪行？别信 Navicat 显示的“行号”
数据库报的“near line X”是它内部解析器扫描到异常 token 时的逻辑行号，不是你文件里的物理行号——前面缺个括号、少个引号、注释没闭合，都会让后续所有行号偏移。实际出错点往往在报错位置往前几行。
- 把报错信息里带引号的关键词（如
"GROUP"、"order"、"user_nam"）直接复制，在 SQL 文件里全局搜索，重点检查它前后的逗号、括号、引号、分号是否配对 - 用 VS Code 或 DataGrip 打开文件，开启对应数据库方言的语法高亮：如果
GROUP BY显示为普通文本色（非关键字色），说明前面漏了ORDER BY或HAVING，解析器根本没进入分组逻辑 - 临时删掉复杂表达式，比如把
jsonb_extract_path_text(data, 'user', 'id')换成data，缩小干扰范围
为什么命令行报错更准？绕过 Navicat 的自动行为
Navicat 会隐式加 USE database_name、自动切分多条语句、补全分号、甚至修正换行格式。这些“贴心”操作掩盖了真实执行上下文。
- MySQL 场景：终端执行
mysql -u root -p mydb &1 | head -n 20，错误直接输出，不含任何修饰 - PostgreSQL 场景：用
psql -U user db -f script.sql -v ON_ERROR_STOP=1，确保第一条错就中断，不被后续语句污染上下文 - 关键区别：命令行不会帮你补
USE，也不会自动识别DELIMITER $$——如果这里报错，说明问题确实在 SQL 本身，不是 Navicat 配置问题
SQL 模式和版本差异常伪装成“语法错误”
ONLY_FULL_GROUP_BY 触发的报错长得很像语法错误，但本质是语义校验；ROW_NUMBER() 在 MySQL 5.7 下报 FUNCTION does not exist，也不是语法错，而是版本不支持。
- 先执行
SELECT @@sql_mode;，确认是否含STRICT_TRANS_TABLES或ONLY_FULL_GROUP_BY - 临时开启严格模式调试：
SET SESSION sql_mode = 'STRICT_TRANS_TABLES';，能让错误更快暴露、位置更准 - 检查目标数据库版本是否支持所用语法：比如含
OVER()的窗口函数、JSON_EXTRACT的路径参数是否为字面量、auto_incrementvsidentity等跨库写法
真正难定位的从来不是“哪行错了”，而是“为什么这行在 Navicat 里不报错，一进命令行就崩”。核心在于：Navicat 的执行环境是伪造的干净现场，而命令行才是数据库看到的真实输入——所有隐藏的编码、BOM、空格、换行、隐式 USE，都在那一刻现形。
