SQLSyntaxErrorException 的根本线索在 getMessage() 中，需结合 getSQLState() 判断错误类型，MyBatis 应开启 DEBUG 日志查看完整 SQL，预编译不防语法错，不同数据库方言差异大，务必在对应 CLI 中验证 SQL。
SQLSyntaxErrorException 出现时，先看 getMessage() 里的具体错误文本
这个异常本身只是容器，真正线索全在它的消息体里。JDBC 驱动通常会把数据库返回的原始语法错误原样塞进 getMessage()，比如 ERROR: column "user_name" does not exist（PostgreSQL）或 You have an error in your SQL syntax; ... near 'ORDER BY'（MySQL）。不读它，就等于蒙眼修 bug。
实操建议：
- 别只打日志
e.toString()，一定要显式打印e.getMessage()和e.getSQLState()（后者能快速区分是语法错、权限错还是连接错） - 如果用的是 MyBatis，开启
log4j.logger.org.apache.ibatis=DEBUG，能看到它拼出来的完整 SQL，比猜强十倍 - 注意：某些驱动（如旧版 MySQL Connector/J）会在消息里自动补空格或截断长 SQL，遇到模糊提示时，加
useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC这类参数未必有用，但换驱动版本可能直接暴露真问题
预编译语句里写死 SQL 字符串，PreparedStatement 也救不了语法错
PreparedStatement 防的是 SQL 注入，不是语法错误。你在字符串里写错关键字、漏括号、用错引号，JDBC 在执行 executeQuery() 时照样抛 SQLSyntaxErrorException —— 它根本不管你是拼接还是预编译。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
-
"SELECT * FROM user WHERE id = ? ORDER BY created_at DESC LIMIT ? OFFSET ?"在 PostgreSQL 里跑不通，因为LIMIT和OFFSET顺序反了（应为OFFSET ? LIMIT ?） - MySQL 用双引号括字段名：
"SELECT \"name\" FROM user"→ 报错，它只认反引号`name` - H2 内存库默认模式是
MySQL，但你代码里写了CREATE TABLE t (id SERIAL)，而 H2 的SERIAL只在PostgreSQL兼容模式下才有效
实操建议：把 SQL 单独抽出来，在对应数据库的 CLI 或 DBeaver 里手动执行一遍，别依赖 Java 环境验证语法。
MyBatis 动态 SQL 的 <if></if> 和 <where></where> 容易拼出非法 SQL
MyBatis 的 XML 标签看似智能，其实只是字符串拼接器。<where></where> 只删开头的 AND 或 OR，不会检查括号是否匹配、逗号是否多余、ORDER BY 后有没有表达式。
典型翻车场景：
-
<where><if test="name != null">AND name = #{name}</if></where>放在UPDATE语句中间，结果生成UPDATE user SET status=1 WHERE AND name = 'a' -
<foreach></foreach>拼IN子句时，集合为空，<foreach></foreach>不渲染任何内容，导致 SQL 变成WHERE id IN ()，MySQL 直接报错 -
<set></set>标签漏写逗号分隔，比如两个<if></if>块之间没空格或换行，拼出name=#{n}age=#{a}
实操建议：打开 MyBatis 的 org.apache.ibatis.jdbc.ScriptRunner 日志级别为 TRACE，它会输出最终送进 JDBC 的 SQL 字符串，复制出来直奔数据库终端验证。
不同数据库对保留字、大小写、引号的处理差异极大
Java 代码里一个 SQL 字符串，换数据库就挂，往往不是逻辑问题，而是方言没对齐。比如 order 是 MySQL 和 PostgreSQL 的保留字，但 SQL Server 要求写成 [order]，Oracle 则必须大写 "ORDER"（且启用了双引号标识符）。
关键差异点：
- MySQL 默认忽略大小写（
SELECT NAME FROM USER≈select name from user），但启用lower_case_table_names=0后，表名大小写敏感，而字段名仍不敏感 - PostgreSQL 所有未加引号的标识符自动转小写，
SELECT UserName FROM User实际查的是username和user表 - SQLite 允许用双引号，但不推荐；它更习惯方括号或反引号，且不支持
WITH RECURSIVE这类高级语法
实操建议：项目启动时通过 DatabaseMetaData.getDatabaseProductName() 和 getDatabaseMajorVersion() 获取真实数据库类型，动态加载对应方言的 SQL 脚本，而不是靠 if-else 硬判断。
复杂点在于，有些错误只在特定组合下触发：比如 HikariCP 的 connection-test-query 设成 SELECT 1，在 Oracle 上就过不去，得写 SELECT 1 FROM DUAL；这种细节不跑集成测试根本露不出来。
