企业官网建设流程全解析

前阵子我面试几位Java后端岗位的候选人，简历上清一色写着熟练使用MyBatis、Spring Data JPA，可我随口问了一句PreparedStatement和Statement有什么区别、JDBC的事务默认提交行为是什么，好几位支支吾吾答不到点上。这个场景让我越来越觉得，JDBC这门技术虽然看起来像是十几年前的老古董，但恰恰是所有Java数据库操作的真正地基。如果你没有系统梳理过JDBC开发实战，遇到数据库性能问题、事务问题、连接泄漏问题，往往只能靠猜。这篇文章我打算把自己做JDBC开发这些年攒下的经验完整讲一遍，从入门六步走到连接池、事务、结果集映射和那些让人半夜抓狂的坑，尽量做到让初学者能照着敲，让有经验的开发者也能找到几个之前没注意到的细节。

1. 框架当道的时代，为什么还要手写JDBC

先说个反直觉的结论：越是框架用得顺手，越应该把JDBC吃透。MyBatis、Spring Data JPA、Hibernate这些工具本质上都是在JDBC外面套了一层壳，帮你省掉了重复的样板代码，但连接怎么建、SQL怎么发、结果集怎么读、异常怎么抛，底层全是JDBC的机制在运作。你排查一个慢查询，最后定位到PreparedStatement的预编译参数传输问题；你排查一个连接池耗尽，最后发现是某个线程拿着Connection忘了归还；你处理一次分布式事务，第一步还是回到本地事务的隔离级别和提交时机。这些场景里，框架只能帮你跑流程，真正决定成败的是你对JDBC本身的理解。

从定义上看，JDBC（Java Database Connectivity）就是Java官方定义的数据库访问标准接口，它把“连接数据库”“执行SQL”“处理结果集”这三件事抽象成了一套统一的API。不同数据库之间的协议、认证方式、数据类型差异极大，但只要厂商提供了对应的驱动JAR，你的Java代码几乎可以原封不动地在MySQL、Oracle、PostgreSQL之间切换。JDBC的设计哲学很像电器行业的插座标准：每个国家的电网标准不一样，但你只要带上对应规格的转换头，就能把电器插上电，而JDBC扮演的就是那个插座的协议层，驱动则是你的转换头。

1.1 框架底层站着的都是JDBC

很多人用MyBatis写了两年业务，还是不清楚一条select * from user最终是怎么变成数据库里的查询的。其实MyBatis的Mapper接口经过代理后，最终会调用到JDBC的PreparedStatement去执行SQL；Spring的JdbcTemplate更是直白，它就是一个帮你管理JDBC资源、执行SQL模板的工具类。包括Spring Data JPA，底层走Hibernate，Hibernate的会话也离不开JDBC Connection。

我见过一位朋友排查一次“MySQL连接被拒”的线上故障，看了半天MyBatis的配置，最后一查是数据库的最大连接数被打满了，而打满的原因是有段代码用原生JDBC获取了连接又没有释放。这个例子说明什么？框架能管好自己创建的那份资源，但只要你绕过框架直接接触了JDBC，就必须按JDBC的规则来。理解不了JDBC，那些抽象层在你眼里就永远是黑盒，出了问题只能重启、加机器、盲目调参数。

1.2 JDBC到底解决了一个什么问题

抛开官腔，JDBC解决的核心问题是：让Java程序员不用背着数据库差异的包袱写数据访问代码。早期的Java要访问数据库，每家厂商给一套私有API，换库就得改代码。JDBC出现后，程序员只要面向java.sql包里的接口写代码，剩下的交给我驱动适配。JDBC标准定义了四大核心组件：DriverManager（加载驱动和获取连接）、Connection（表示一个数据库会话）、Statement（执行静态SQL）、ResultSet（封装查询结果的游标）。后来的PreparedStatement、DataSource、BatchUpdate等都是在这些基础组件上做的演进。

理解这个设计，对你实际工作的帮助是：你在写JDBC代码时，不要局限于“能用就行”，而要时刻问一句“这里抽象了什么”。比如DriverManager.getConnection()为什么每次都要新建一条TCP连接？PreparedStatement为什么要做预编译？ResultSet为什么像游标一样只能一路向前读？这些问题想通了，后面的性能优化和问题排查自然就有思路了。

1.3 我的学习路线建议

如果你是从零开始，我建议按这个顺序推进：先熟练掌握一次完整CRUD的六步流程，然后深入研究PreparedStatement为何能防注入、预编译比字符串拼接好在哪，接着搞懂结果集遍历和元数据映射，再进入事务控制，最后认真对待连接池和异常处理。文章接下来的章节就基本按这个顺序展开，每一部分我都会结合真实代码和踩坑案例来讲，而不是把API文档复述一遍。

2. 第一个JDBC程序：六步走完一次数据库操作

在动手之前，先把环境准备好。我这里以MySQL为例，因为它是最常见的入门数据库。使用Maven管理依赖的话，需要在pom.xml里加入MySQL驱动：

<dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.33</version> </dependency>

如果不用Maven，就直接把驱动JAR包放到项目的classpath里。Java 6之后JDBC驱动可以通过SPI机制自动注册，所以比较新的驱动版本不再强制要求Class.forName那一步了。但很多老项目和教程还在写：

Class.forName("com.mysql.cj.jdbc.Driver");

这行代码的作用是显式加载驱动类，让DriverManager能识别这个驱动。写不写都能跑，我建议新手保留它，至少能让你明白“驱动是Java里一个普通类，加载之后才生效”，也方便排查类冲突问题。另外注意驱动类名变化：MySQL 5.x常用com.mysql.jdbc.Driver，MySQL 8.x推荐com.mysql.cj.jdbc.Driver，别配错。

2.1 连接参数：URL里的门道

获取连接必须准备好四个参数：驱动类名、连接URL、用户名、密码。以本地MySQL为例：

jdbc:mysql://localhost:3306/yourdb?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8

这个URL看起来很长，每个参数都有讲究。useSSL=false是为了避免本地开发时MySQL因SSL握手带来额外开销和告警；serverTimezone=Asia/Shanghai用来解决数据库和Java应用时区不一致导致的日期偏差；characterEncoding=utf8保证中文不会在传输过程中变成乱码。这三个参数看起来无关紧要，却是新手第一个月的坑：时区没配，查出来的时间总是差8小时；编码没配，中文全变成问号。

2.2 六步流程逐行拆解

一个查询用户表的最小完整Demo如下：

String url = "jdbc:mysql://localhost:3306/yourdb?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"; String user = "root"; String password = "yourpassword"; // 第一步：加载驱动 Class.forName("com.mysql.cj.jdbc.Driver"); // 第二步：获取连接 Connection conn = DriverManager.getConnection(url, user, password); // 第三步：创建Statement Statement stmt = conn.createStatement(); // 第四步：执行SQL，返回结果集 ResultSet rs = stmt.executeQuery("SELECT id, name, email FROM user"); // 第五步：遍历结果集 while (rs.next()) { Integer id = rs.getInt("id"); String name = rs.getString("name"); String email = rs.getString("email"); System.out.println(id + " - " + name + " - " + email); } // 第六步：依次关闭rs、stmt、conn rs.close(); stmt.close(); conn.close();

这就是传说中的“六步法”。第一步到第二步是建立连接，第三步到第四步是发送并执行SQL，第五步是读取结果，第六步是清理资源。对于增删改操作，第四步换成executeUpdate()即可，返回的是受影响的行数。整个流程并不复杂，复杂的是每一步在真实项目中都可能优化和踩坑。比如“获取连接”这一步，在分库分表环境下要路由到正确的库；创建Statement这一步，正常要选PreparedStatement；关闭资源这一步，很多人写着写着就漏了一行。

2.3 资源关闭：忘掉Close的代价

新手最容易忽略的就是资源关闭。注意上面Demo里我是手动按顺序关闭的，顺序不能乱：先关ResultSet，再关Statement，最后关Connection。如果只关Connection，很多驱动在连接关闭时也会尝试回收Statement和ResultSet，但依赖这个隐式行为等于埋雷。更严重的场景是用连接池时，Connection.close()并不真正断开数据库连接，而是把连接归还给池子，如果你没有关闭Statement，一些池化实现会警告“Statement 泄漏”。

Java 7之后有更好的写法：try-with-resources，它保证无论正常执行还是抛异常，资源都会按照声明的逆序自动关闭：

String sql = "SELECT id, name, email FROM user WHERE id = ?"; try (Connection conn = DriverManager.getConnection(url, user, password); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, userId); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { // 处理每行数据 } } }

我强烈建议所有新代码都用这种形式，它把“忘记关闭”这个根因直接干掉了。有个容易被忽略的细节：try-with-resources中一旦先声明Connection再声明Statement，关闭顺序会自动处理成先关Statement再关Connection，和手动关闭的推荐顺序保持一致。也就是说，资源之间不能存在反向依赖，而这里Connection被Statement依赖，所以声明顺序别反过来写。

3. PreparedStatement：为什么字符串拼SQL会让你在面试和线上同时翻车

用Statement执行SQL最直观，比如：

Statement stmt = conn.createStatement(); stmt.executeQuery("SELECT * FROM user WHERE name = '" + name + "'");

多简单啊，直接拼字符串。但这行代码在生产环境里就是一个定时炸弹。

3.1 一次拼接引发的SQL注入事故模拟

假设登录接口接收用户输入的name，正常输入是Alice，拼接后的SQL是：

SELECT * FROM user WHERE name = 'Alice'

但攻击者输入的是：

' OR '1'='1

拼接后就变成了：

SELECT * FROM user WHERE name = '' OR '1'='1'

这个SQL的WHERE条件永远为真，攻击者不需要知道任何密码就能绕过登录。如果再配合; DROP TABLE user; --之类的语句，后果更不堪设想。这个经典案例我在培训新人的时候必讲，每次都有同学觉得“就这么一个引号也能出事故”，但实际上SQL注入直到今天都是OWASP Top10里的常客，核心原因就是太多人习惯用字符串拼接拼SQL。

3.2 预编译的优势：性能、语义、安全

PreparedStatement解决这个问题的思路是：SQL骨架和参数分离。SQL先被发送到数据库进行预编译，数据库把语句解析成执行计划，后续传入的参数只当作纯数据，不再参与语句结构解析。这相当于点菜的时候你先说清楚了要“两份米饭”，后厨按订单备好，之后你说“加个蛋”，那就真的只是加个蛋，不可能把菜单结构给改了。

用PreparedStatement改造上面的登录查询：

String sql = "SELECT * FROM user WHERE name = ?"; try (PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, name); try (ResultSet rs = ps.executeQuery()) { // 处理结果 } }

预编译带来的另一个收益是性能。同一个SQL在多条数据下反复执行时，数据库端可以复用执行计划，不需要每次都重新解析SQL。批量插入几百条数据时，用PreparedStatement配合addBatch，性能往往是逐条拼SQL的好几倍。最后从代码可维护性角度看，参数集中设置以后，SQL带引号、转义、日期格式这些麻烦事都交给驱动处理了。

3.3 占位符使用的几个实用细节

使用PreparedStatement时有几个细节值得记住：占位符索引从1开始，不是0；不同类型用对应的setter，比如setString、setInt、setTimestamp。最容易被忽略的是字段为NULL时的写法，正确方式是指定JDBC类型：

ps.setNull(3, Types.VARCHAR);

有人图省事直接写ps.setString(3, null)，个别驱动行为不一致，容易埋坑。另外，占位符不能用于表名、列名这类SQL结构位置，比如写SELECT * FROM ? WHERE ?是不行的，因为数据库在预编译阶段就必须确定完整的语句结构。遇到动态表名这种需求，应该通过白名单校验后再拼接，不能用参数化方式硬塞。

还有个高频场景是批量操作。一次插入一万条数据，如果一条一条执行Insert，耗时可能要好几十秒；用批量后能压缩到一两秒：

String insertSql = "INSERT INTO user(name, email) VALUES(?, ?)"; try (PreparedStatement ps = conn.prepareStatement(insertSql)) { for (User u : userList) { ps.setString(1, u.getName()); ps.setString(2, u.getEmail()); ps.addBatch(); if (batchCount % 500 == 0) { ps.executeBatch(); ps.clearBatch(); } } ps.executeBatch(); }

这里500条一批是为了避免单次批处理SQL过长或内存堆积，在MySQL 8驱动下如果想更进一步提速，可以在JDBC URL上开启rewriteBatchedStatements=true，驱动会把多条INSERT改写成一条多值的INSERT语句，性能又能上一个台阶。这个参数后面第8章会再提到，很多人不知道它存在。

4. 结果集映射：从getString到自动封装的进阶路径

JDBC最繁琐的部分不是执行SQL，而是把ResultSet里的数据转换成Java对象。初学者最容易写出一大堆重复的rs.getXxx("列名")，但是到项目中期你会发现，这个套路在表结构变了、查询字段多了之后就特别难维护。

4.1 ResultSet的基本用法与游标机制

ResultSet在设计上很像一个只能向前移动的游标。刚拿到结果集时，游标位于第一行之前，调用一次next()就向下移动一行，返回true表示还有数据；当返回false时说明已经读完。默认情况下这个游标只能单方向移动，虽然可以通过TYPE_SCROLL_INSENSITIVE等参数创建可滚动的结果集，但绝大多数场景没必要，因为数据库本身不太适合做“回退一行”这种操作。

取字段值时我建议优先按列名取，不要按索引：

rs.getString("name");

而不是：

rs.getString(2);

列名方式的好处是SQL里加了字段或者调整了字段顺序，代码不用跟着改。但要注意，如果SQL里用了别名，比如SELECT COUNT(*) AS cnt FROM user，那么取值要用别名rs.getInt("cnt")。有个隐藏的坑是列名重复，比如连表查询时两张表都有id列，这时用列名取值会取到第一个匹配项。解决办法是SQL里给列加上明确别名。

4.2 用元数据写一个最小化的通用查询工具

如果你想了解ORM框架自动映射的原理，最简单的方式是自己写一次。JDBC提供的ResultSetMetaData可以获取结果集的列信息，拿到列名和类型之后，用rs.getObject()把值取出来放进Map，就实现了“任意SQL返回任意结果列表”的效果：

public static List<Map<String, Object>> query(String sql, Object... params) { List<Map<String, Object>> rows = new ArrayList<>(); try (Connection conn = JdbcUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { for (int i = 0; i < params.length; i++) { ps.setObject(i + 1, params[i]); } try (ResultSet rs = ps.executeQuery()) { ResultSetMetaData meta = rs.getMetaData(); int colCount = meta.getColumnCount(); while (rs.next()) { Map<String, Object> row = new HashMap<>(); for (int i = 1; i <= colCount; i++) { String colName = meta.getColumnLabel(i); row.put(colName, rs.getObject(i)); } rows.add(row); } } } catch (SQLException e) { throw new RuntimeException("查询失败", e); } return rows; }

这个工具类在生产里当然还需要扩充，比如处理类型转换、列名冲突、SQL日志等，但核心思路已经和很多轻量ORM的底层一致了：拿元数据，反射或Map填充对象。理解了这一层，你再去看MyBatis的ResultMap、Spring JDBC的RowMapper，会发现它们都只是在列名和Java属性之间建立映射关系，本质并不神秘。

4.3 大数据量场景：fetchSize与内存控制

默认情况下，MySQL驱动会把查询结果一次性全部加载到JVM内存中。如果一张表有几百万行，你只是想统计一下数据或者流式处理，这种默认行为会直接OutOfMemory。JDBC提供了setFetchSize()来控制单次从数据库抓取的行数，但值得注意的是它在不同数据库里的行为差异很大。在MySQL 8中，setFetchSize(Integer.MIN_VALUE)是流式读取的经典做法，或者更稳妥的方式是在JDBC URL里配置：

useCursorFetch=true&defaultFetchSize=100

开启之后Statement每次只取100行，处理完再向数据库取下一批，内存占用就能保持平稳。在Oracle里行为又不完全一样，所以我每次换数据库都要专门测试一遍。这个细节在面试里也经常被问到：怎么保证百万行数据查询不会把内存打爆。正确回答不是“用分页”，而是说清楚ResultSet默认缓冲策略和fetchSize的作用，然后结合业务用游标、流式读取或分页来做。

5. 事务：银行转账的教科书里没说的JDBC细节

事务的经典例子是转账：从A账户扣100元，给B账户加100元，两个步骤要么都成功，要么都失败。但很多人在框架里用惯了@Transactional，反而不清楚JDBC层的事务到底是怎么控制提交和回滚的。

5.1 默认的自动提交模式

Connection默认处于自动提交模式：每执行一条SQL，成功后就立即提交。这意味着你执行第一条UPDATE扣钱，它已经提交了；如果第二条加钱SQL执行失败，第一条不会自动回滚，最终A少了钱，B却没多钱。这就是为什么每条更新操作都能跑，但组合起来就是错的。

开启手动事务的方式很简单：

conn.setAutoCommit(false);

这句话告诉数据库：别急着提交，等我发指令。之后所有在这个Connection上执行的SQL都会聚合到同一个事务里，直到你显式调用commit()或rollback()。

5.2 事务的完整代码范式

一段规范的JPAt事务代码长这样：

String sql1 = "UPDATE account SET balance = balance - 100 WHERE id = 1"; String sql2 = "UPDATE account SET balance = balance + 100 WHERE id = 2"; try (Connection conn = JdbcUtil.getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps1 = conn.prepareStatement(sql1); PreparedStatement ps2 = conn.prepareStatement(sql2)) { ps1.executeUpdate(); ps2.executeUpdate(); conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } finally { conn.setAutoCommit(true); } }

有几个细节值得留意。第一，两条更新必须使用同一个Connection，因为事务的边界是数据库会话级别的，换连接就等于换事务，这也是“声明式事务和连接绑定”的根本原因。第二，rollback()放在catch里，一旦出错了要主动回滚。第三，finally里把自动提交恢复成true，否则这个连接归还给连接池后，下一个使用它的线程会继承一个不自动提交的“脏状态”，业务会很诡异。

5.3 隔离级别与脏读

事务最容易被忽略的问题是并发。两个事务同时读同一份数据，如果隔离级别控制不当，就会发生脏读、不可重复读、幻读等问题。JDBC允许你通过setTransactionIsolation(int level)设置隔离级别，JDBC标准定义了五种隔离级别，其中和我们相关的主要是四种：

MySQL InnoDB的默认隔离级别是REPEATABLE_READ，Oracle的默认级别是READ_COMMITTED，这也是为什么同一套代码在两个数据库上表现可能不一样。脏读是“一个事务读到了另一个事务未提交的数据”，这种数据可能随时被回滚，拿它做业务判断非常危险。不可重复读是同一行数据在一个事务里两次读取结果不一致；幻读侧重的是“多出来几行”。在比较高并发的账务类系统里，除了设置隔离级别，还会配合SELECT ... FOR UPDATE这类行级锁来保证关键读写的串行化，这个就属于临界区设计的更深话题了，JDBC只是提供了API，真正的决策还是要靠你理解具体业务。

6. 连接池：从new Connection到池化复用，性能差距在哪里

初学者写完连接、关闭的Demo之后，很容易产生一个疑问：每次操作数据库都新开一个Connection，这不是很慢吗？确实很慢。

6.1 连接创建为什么慢

一次DriverManager.getConnection()背后要做的事情远超你的直觉：客户端发起到数据库服务器的TCP三次握手，数据库验证用户名和密码，分配会话内存，初始化会话状态，再处理SSL握手的协商……整个过程在网络正常时也要几十到几百毫秒。数据库连接是有限资源，如果每个请求都新建连接、用完又断开，在高并发下不仅是慢的问题，还会直接把数据库的连接数打满，新的请求全部排队或报错。

连接池的核心思路就一句话：把连接“对象”和底层的数据库“会话”分离。连接池预先创建一批连接放在池子里，业务需要时借出去一个，用完了不是物理关闭，而是归还进池子复用。这相当于以前每次买东西都现开一家店，现在改成在一家大超市里租个货柜。

6.2 一个连接池要解决的完整问题清单

一个成熟的连接池并不只是“维护几个连接”那么简单，它至少要处理以下问题：

• 连接复用：借出和归还的接口要足够轻，尽量不增加业务代码负担；
• 连接保活：池里的连接如果长时间空闲，可能被数据库主动断开，借出之前校验一下连接是否可用；
• 连接上限控制：池的最大连接数不能无限大，否则应用自身成为瓶颈，所以要有等待队列和超时策略；
• 泄漏检测：如果业务代码借了连接没归还，池子要能检测并兜底回收；
• 动态伸缩：低峰期收缩到最小空闲数，高峰期逐渐扩张到最大连接数，避免频繁建连。

我在配置生产环境的连接池参数时，常用这么一组初始值做参考：

maximumPoolSize=20 minimumIdle=5 connectionTimeout=30000 idleTimeout=600000 maxLifetime=1800000

最大连接数不能盲目调大，一般结合应用机器的核数和数据库负载来定；连接超时30秒意味着借不到连接最多等这么久，再久就直接报错；maxLifetime要略小于数据库端连接超时时间，让池子主动替换连接，避免被数据库端杀连接。

6.3 池化环境下Connection.close()的真实含义

这可能是最容易混淆的一点：连接池场景下你调用connection.close()，连接并没有真正关闭，而是被归还到池子里。因此必须把传统JDBC“用完即焚”的思维切换到“借完就还”的思维。如果你在代码里额外调用了驱动底层的物理关闭方法，或者把Connection对象保存到了静态变量里，就可能造成两种极端后果：连接池耗尽，或者多个线程共用一条连接导致数据错乱。正确做法是让每个方法内部自己获取连接、自己归还，永远不要把Connection作为共享对象跨线程传递。

另一个常见场景是在连接池里执行事务。前面的事务代码之所以在finally里恢复setAutoCommit(true)，正是因为归还给池子的连接必须保持干净状态。如果忘了恢复，池里所有连接都会慢慢变成不自动提交，后续业务查询就会读到旧数据，线上排查这类问题通常特别崩溃。

7. 异常处理与DAO层设计：把烂摊子收拾得井井有条

只要接触到真实项目，你一定会遇到SQLException的暴击。很多新手在catch里写一句e.printStackTrace()就继续往下走，这等于把错误吞进日志里，然后业务数据悄悄出错，后续排查成本极高。

7.1 SQLException的分类与关键信息

SQLException携带的信息远不止消息文本，它还包含SQLState（符合SQL标准的错误状态码）、errorCode（数据库厂商自定义错误码）、以及引发异常的原始SQL。某些操作比如批量更新失败，会抛BatchUpdateException，它额外保留了每条SQL执行成功的状态数组，用来精确判断哪一批哪一条失败。处理数据库异常时第一个原则是：别吞异常，至少要记录错误码和上下文。第二个原则是：区分“可预期的业务异常”和“不可预期的系统异常”。比如唯一键冲突，SQLIntegrityConstraintViolationException就是一种可预期的业务校验结果，你可以在DAO层捕获它并转换成自定义业务异常再抛出去，而不是让上层接口直接暴露“SQL完整性约束违反”这种话术。

7.2 事务回滚和异常的正确配合

在事务代码里，捕获到异常后回滚是标准动作，但还有一个细节经常被忽略：回滚之后是否需要关闭连接、是否需要重新设置隔离级别。我曾经在一个长任务里开启了事务，执行到一半遇到校验异常，直接调用了rollback()然后继续复用同一个连接执行下一个任务，结果下一个任务也莫名被卷进同一个事务的残留状态里。正确的做法是：事务边界一定要清晰，出了这个边界就把连接恢复到可复用的初始状态。

还有一点，不要在大范围catch块里调用事务提交。如果你在事务中间做了一步可能是空操作的处理，然后随手commit()了，整个事务就没了，后续出错的SQL再回滚也只能回滚到提交点之后。核心原则是：一个事务对应一个提交点，提交/回滚只能在各分支统一收口的位置调用。

7.3 DAO层封装的三层思想

JDBC本身的使用粒度非常低，如果业务代码到处散落连接获取、Statement创建、结果集映射，项目会迅速变成一团乱麻。因此实践中我会先封装一个JdbcUtil工具类，统一负责连接的获取和资源关闭，然后再建一层DAO来管理SQL与实体映射。

一个简化版JdbcUtil看起来像这样：

public final class JdbcUtil { private JdbcUtil() {} private static final String URL = loadUrl(); private static final String USER = loadUser(); private static final String PASSWORD = loadPassword(); private static String loadUrl() { // 从配置中心或环境变量读取 } public static Connection getConnection() throws SQLException { return DriverManager.getConnection(URL, USER, PASSWORD); } public static void close(AutoCloseable... resources) { for (AutoCloseable resource : resources) { if (resource != null) { try { resource.close(); } catch (Exception e) { // 记录日志，关闭资源本身不该阻塞主流程 } } } } }

然后DAO层负责业务SQL，例如：

public User findById(Long id) { String sql = "SELECT id, name, email FROM user WHERE id = ?"; try (Connection conn = JdbcUtil.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setLong(1, id); try (ResultSet rs = ps.executeQuery()) { if (rs.next()) { User user = new User(); user.setId(rs.getLong("id")); user.setName(rs.getString("name")); user.setEmail(rs.getString("email")); return user; } } } catch (SQLException e) { throw new DataAccessException("查询用户失败, id=" + id, e); } return null; }

往上可以是Service层，负责业务编排和事务边界，再往上才是Controller。分层并不是为了代码显得“高级”，而是为了让每个职责变化时只改动一层：换数据库连接池配置改JdbcUtil，改表结构只动DAO，改业务规则只动Service。后期接入了Spring之后，这些逻辑可以被模板类替代，但思路依然一脉相承。

8. 几个我踩过才会记得的JDBC坑

前面几章已经穿插了一些坑，最后我再集中讲三个投入产出比最高的，每个都是真实项目里能让你熬夜排查的级别。

8.1 时区与编码：连接参数写错的诡异现象

有一个夏季的某天凌晨，运维反馈应用写入的时间比当前时间多了8小时。第一反应是服务器时区问题，查下来系统时区是UTC，应用时区也正常，最后定位到JDBC URL没有配置serverTimezone=Asia/Shanghai。MySQL驱动在默认情况下会用服务器的时区来解析日期，服务器是UTC，JVM是北京时间，时间戳在转成字符串时就会产生8小时偏移。类似的问题还有中文乱码，本质上就是客户端和数据库之间的字符集没对齐。解决办法就是在一开始把URL参数写完整，哪怕现在觉得多此一举，也别给自己埋定时炸弹：

useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8

8.2 连接池连接“看似过期”的诡异行为

有次排查一个偶发性的查询超时，应用日志里没有明显异常，只是偶尔有一条SQL执行特别慢。后来发现是连接池里的空闲连接被数据库服务端断开了，而池子不知道，连接这一侧还呆着等响应，导致请求卡住直到超时。解决方案是在连接池里配置合适的socketTimeout和连接池侧的保活机制，同时把maxLifetime设置成小于数据库端连接回收时间。这件事提醒我：连接池不是配完就万事大吉，连接保活、过期校验这些参数需要和数据库的wait_timeout联动考虑。

8.3 批量更新性能差？试试驱动级改写

第一次用JDBC批量更新时，我以为addBatch之后调用executeBatch()，驱动就会把SQL打包发送给数据库。后来对一批1万行的插入做性能压测，发现耗时和逐条插没什么区别，查了驱动文档才明白：MySQL JDBC驱动默认执行批量更新时还是逐条发给数据库，真正的性能提升需要开启rewriteBatchedStatements=true。这个参数开启后，驱动会把批量语句重写成多值语法，比如一次INSERT带多条VALUES，网络交互次数急剧减少，1万行插入从几十秒降到几秒。另外它只影响INSERT/UPDATE/DELETE这类DML，对SELECT没有作用。配置方法是把它加到JDBC URL末尾：

jdbc:mysql://localhost:3306/yourdb?rewriteBatchedStatements=true

篇幅差不多了，再分享一个我自己的习惯：每次遇到数据库相关报错，我都会先确认连接参数和事务边界，再去翻框架文档。这两处的问题，十次里能占七次。JDBC里最不显眼的细节，往往就是线上事故的根源。希望这篇实战梳理能让你少走几步弯路，把JDBC真正变成你工具箱里最可靠的那把扳手。