Java数据库操作抛出SQLException怎么排查_连接超时与语法错误分析-java教程-PHP中文网

应抓执行前的真实sql定位sqlexception：mysql加profilesql=true，postgresql设loglevel=2，spring boot配jdbctemplate=debug；区分sqltimeoutexception（含timeout）与sqlsyntaxerrorexception（含ora-00900等）；preparedstatement不校验列名/表名，需检查拼写、大小写及类型匹配；connection.isvalid()为轻量检测，不代表可执行业务sql。

java数据库操作抛出sqlexception怎么排查_连接超时与语法错误分析

SQLException 报错但没看到具体 SQL，怎么快速定位问题

多数 SQLException 不会直接打印出错的 SQL 语句，尤其用 PreparedStatement 时，你看到的只是“ORA-00942”或“MySQLSyntaxErrorException”，根本不知道哪条 SQL 撞上了。关键不是看异常类名，而是抓执行前的真实 SQL。

开启 JDBC 驱动日志：MySQL 加 jdbc:mysql://host/db?logger=com.mysql.cj.log.StandardLogger&profileSQL=true；PostgreSQL 用 logLevel=2 参数
Spring Boot 用户更简单：在 application.yml 加 logging.level.org.springframework.jdbc.core.JdbcTemplate=DEBUG，能打出绑定参数后的完整 SQL
别信 DAO 层日志里“执行了 update user set name = ?”，那个 ? 还没替换——真正出错的是数据库执行时的最终语句

连接超时（SQLTimeoutException）和语法错误（SQLSyntaxErrorException）怎么一眼区分

这两类异常看着都是 SQLException 子类，但处理路径完全不同：一个是网络/配置问题，一个是代码写错了。光看堆栈容易误判。

SQLTimeoutException 一定带 “timeout” 或 “socket read timed out”，且通常出现在 executeQuery() 或 executeUpdate() 调用处，不是在 prepare 阶段
SQLSyntaxErrorException 一定含数据库特有错误码：MySQL 是 “You have an error in your SQL syntax”，Oracle 是 “ORA-00900”，PostgreSQL 是 “ERROR: syntax error at or near”
注意：MyBatis 报 org.apache.ibatis.exceptions.PersistenceException 包裹的底层异常才是真凶，得点开 Caused by: 才能看到是语法错还是超时

PreparedStatement 参数绑定后还报“列不存在”或“类型不匹配”

用了 PreparedStatement 就以为万无一失？其实参数绑定只解决注入和类型转换，不校验列名、表名、函数名这些静态结构。这类错往往在预编译阶段就失败，但有些驱动（如旧版 MySQL Connector/J）会延迟到执行才抛。

Java Maven Code Review

审查Java Maven项目（ZIP压缩包或GitLab仓库URL），检查代码规范、命名、模块边界、可维护性问题以及重复代码。

下载

检查拼写：SELECT user_name FROM users 写成 user_nam，驱动不会帮你补全，也不会提示“建议是否是 user_name”
大小写敏感：PostgreSQL 默认区分大小写，"UserName" 和 username 是两个东西；MySQL 在 Linux 下也区分表名大小写
别把字符串当数字传：ps.setInt(1, "123") 编译不过，但 ps.setString(1, "123") 传给 INT 字段，某些数据库（如 H2）会静默转，而 MySQL 8.0+ 默认会报 data truncation

Connection.isValid() 返回 true 却执行 SQL 失败

这是最骗人的假阳性。连接池（比如 HikariCP）里的连接可能刚被校验过，但紧接着网络抖动、数据库 kill 了该会话、或防火墙中断了长连接，isValid() 校验完下一毫秒就失效了。

isValid(1) 只发一个轻量 ping，不代表能执行真实业务 SQL——它不走查询计划器，也不校验权限
遇到“Connection closed”或“Communications link failure”，别急着重连，先查数据库端有没有 KILL 掉这个线程，或看连接池配置的 maxLifetime 是否小于数据库的 wait_timeout
HikariCP 推荐关掉 connectionTestBeforeUse（已废弃），改用 connectionInitSql 或更可靠的 validationTimeout + keepaliveTime