JDBC连接数据库全攻略：配置、排错与连接池实战

周一早上刚到工位，隔壁组的小王就抱着笔记本过来了：“哥，我连不上数据库了，报错是CommunicationsException，但昨天还好好的。”这种问题我一年少说碰十几次，每次排查到最后，绝大多数情况都回到同一个原点——用JDBC连接数据库时，某些配置细节没做对。

JDBC这个名字，干了几年Java的人都不会陌生，但说实话，真正把它吃透的人不多。很多人天天用MyBatis、Spring Data JPA，以为JDBC只是底层的一个名词，其实不管是ORM框架还是连接池，最终落到数据库的二进制协议上，走的还是JDBC这套规范。搞懂JDBC连接数据库，等于把Java访问数据库这条链路的地基打实了。这篇文章不写空理论，就围绕“JDBC怎么连上数据库、连接参数怎么配、连不上怎么排查、连上了怎么安全地做增删改查”这几个核心问题，把实操和坑一次说清楚。适合刚入门的新手，也适合被连接问题折磨过、想系统补一遍的Java开发。

1. 搞清楚JDBC到底解决了什么问题

1.1 没有JDBC之前，Java连数据库是什么样

很多教材上来就讲JDBC API，但很少讲它为什么存在。回到Java刚诞生的年代，各家数据库厂商都有自己的通信协议，如果你的业务系统要同时支持Oracle和MySQL，就得分别调用两套完全不同的客户端库，代码里全是厂商相关的东西。换数据库等于重写数据访问层，这谁受得了。

JDBC（Java Database Connectivity）做的事就是定了一套统一接口：DriverManager负责管理驱动，Connection表示一个连接，Statement负责执行SQL，ResultSet封装查询结果。数据库厂商按照这套接口各自实现自己的驱动，Java程序员只需要面向JDBC接口编程。打个比方，JDBC就相当于电器上的国标插座，不管你买的是哪家电器，只要插头是国标，插上就能用。数据库厂商的驱动就是那个把国标插头转换到各自内部电路的转接头。

这套设计带来的直接好处有两个：一是应用层的代码和数据库厂商解耦，迁移数据库时只需要换驱动和调整部分SQL方言；二是所有Java生态的工具，从连接池到ORM框架，都可以建立在同一套抽象之上。你去看Druid、HikariCP、MyBatis的源码，底层处理的全是java.sql包下的这套接口，这也是为什么我说不管用不用框架，JDBC的核心机制都值得认真过一遍。

1.2 一次JDBC连接的核心链路拆解

一次完整的JDBC连接流程，比很多人想象的要复杂。简单说分五步：加载驱动、获取连接、创建Statement、执行SQL、释放资源。但每一步背后都有值得深挖的点。

加载驱动这一步，在老版本里需要显式执行Class.forName("com.mysql.cj.jdbc.Driver")，目的是让驱动类被JVM加载，并在静态代码块里把自己注册到DriverManager。JDBC 4.0之后，只要驱动jar包在classpath里，JVM会通过ServiceLoader机制自动发现驱动，这行代码可以省略。但有些老项目里还保留着，我建议别急着删，原因后面在排查部分会细说。

获取连接是重点。DriverManager.getConnection(url, username, password)做的事包括：解析URL、匹配合适的驱动、建立TCP连接、完成握手认证、初始化会话参数。这个过程的耗时通常是几百毫秒到几秒不等，取决于网络和数据库负载。正因如此，生产环境绝对不能每执行一次SQL就新建连接，必须有连接池兜底。

创建Statement和执行SQL这步，初学者最容易踩的坑就是直接拼字符串。SELECT * FROM user WHERE name = '+ name +'这种写法，一旦name里有单引号，轻则SQL报错，重则被注入。后面我会专门讲PreparedStatement的正确姿势。

释放资源这步最容易被忽略。Java里Connection、Statement、ResultSet都持有底层资源，不关闭会导致连接泄露。如果用了连接池，连接不归还，连接池的连接最终会被耗尽，表现为“连接数用完、新请求全部超时”。这种问题隐蔽，排查起来也费劲。

2. 驱动选型和连接配置，90%的连接问题都出在这里

2.1 四种JDBC驱动类型，以及你现在应该怎么选

教科书上把JDBC驱动分成四类：JDBC-ODBC桥接驱动、本地API驱动、网络协议驱动、纯Java驱动。前两类基本可以当历史故事听，现在主流场景下用的几乎都是纯Java驱动，也就是Type 4驱动，它直接通过Socket和数据库的底层协议通信，不依赖任何本地库。

选驱动时最容易忽略的是版本匹配。拿MySQL来说，mysql-connector-java从8.0.31之后版本号变成了com.mysql:mysql-connector-j，包名从com.mysql.jdbc.Driver改成了com.mysql.cj.jdbc.Driver。如果你还在用5.x时代的URL模板，连8.x驱动，大概率会踩时区或SSL的坑。另外驱动版本和数据库版本不需要严格一一对应，但建议驱动版本别低于数据库大版本，因为旧驱动可能不认识新数据库的认证插件或新特性。

这里给一个我常用的驱动选择参考表：

数据库	驱动类	典型Maven坐标
MySQL 5.x	com.mysql.jdbc.Driver	mysql:mysql-connector-java:5.1.49
MySQL 8.x+	com.mysql.cj.jdbc.Driver	com.mysql:mysql-connector-j:8.4.0
PostgreSQL	org.postgresql.Driver	org.postgresql:postgresql:42.7.x
Oracle	oracle.jdbc.OracleDriver	com.oracle.database.jdbc:ojdbc11
SQL Server	com.microsoft.sqlserver.jdbc.SQLServerDriver	com.microsoft.sqlserver:mssql-jdbc:12.x

有一个经验：驱动jar包宁多勿缺，但别在classpath里塞两个版本的同一个驱动，JVM加载类时可能随机命中其中一个，导致你改了配置却不生效，这种问题最坑。

2.2 URL里的每个参数到底是什么意思

JDBC URL是连接配置的核心，很多连接失败的根源是对URL理解不透。以MySQL 8.x为例，标准格式是这样：

jdbc:mysql://host:port/database?参数名=参数值&参数名=参数值

逐个拆开看。jdbc:mysql:是协议前缀，DriverManager靠这个前缀来定位具体驱动。如果拼错成jdbc:mysq，系统会提示找不到合适的驱动。host和port是数据库服务器的网络地址和端口，MySQL默认3306，PostgreSQL默认5432，Oracle默认1521。database是你要连接的库名，不是数据库服务器的实例名。

URL后面跟的参数才是真正的坑聚集地。useSSL=false或者sslMode=DISABLED，不加的话8.x驱动默认开启SSL，很多内网环境没配证书，连接阶段会各种握手失败。serverTimezone=Asia/Shanghai，不加的话驱动会用JVM默认时区去解释数据库返回的时间类型，一旦两边时区不一致，查出来的时间就会差8小时。allowPublicKeyRetrieval=true，这个参数和MySQL 8的caching_sha2_password认证插件有关，如果服务器用的就是这个插件，且连接走的是非SSL通道，必须允许客户端获取公钥，否则报错Public Key Retrieval is not allowed。

PostgreSQL的URL格式稍有不同，参数用?连接，但常见参数比如currentSchema、stringtype=unspecified也有各自的用途。所以我的建议是：不管用哪个数据库，都去官方文档里把URL参数列表翻一遍，花十分钟，能省好几个小时排查问题的时间。

2.3 连接参数里容易被忽略的“连接池级别”配置

单条连接的URL参数解决的是“能不能连上”的问题，但“连上之后稳不稳”还取决于一批连接池级别的配置。很多人只配了maximumPoolSize就以为完事了，其实关键的还有三个。

第一个是connectionTimeout，也就是从连接池获取连接的等待时间，默认30秒。我遇到过系统卡死的情况，数据库没挂，连接池的连接全被慢查询占住了，新请求都在排队等连接，表现为接口全部超时。如果connectionTimeout设成5秒，系统会快速失败而不是无限等待。

第二个是idleTimeout和maxLifetime。idleTimeout是空闲连接多久被回收，maxLifetime是连接最多存活多久。数据库服务器一般有自己的wait_timeout，默认8小时，如果连接池里的连接超过这个时间但池子没做检测，下次使用会拿到一个物理上已断开的连接，执行第一条SQL时才报错。所以连接池的maxLifetime要小于数据库的wait_timeout。

第三个是validationTimeout和连接测试机制。常用的方案是连接获取时执行一条SELECT 1，确保物理连接是活的。HikariCP默认没有强制检测，但你可以在JDBC URL里加connectionTestStatement，或者在池配置里开isValid检测。生产环境建议开，否则半夜数据库重启一次，早上第一波流量可能全是连接错误。

3. 手把手写一个标准的JDBC连接读取流程

3.1 从加载驱动到拿到Connection，完整步骤

下面这段代码是标准的JDBC连接写法，我特意保留了try-with-resources的写法，因为这是Java 7引入后最不容易泄漏资源的姿势：

import java.sql.Connection; import java.sql.DriverManager; import java.sql.SQLException; import java.util.Properties; public class JdbcConnectionDemo { public static void main(String[] args) { String url = "jdbc:mysql://127.0.0.1:3306/demo_db" + "?useSSL=false" + "&serverTimezone=Asia/Shanghai" + "&allowPublicKeyRetrieval=true" + "&characterEncoding=utf8"; Properties props = new Properties(); props.setProperty("user", "app_user"); props.setProperty("password", "your_password"); // 连接超时设置，单位是毫秒 props.setProperty("connectTimeout", "5000"); props.setProperty("socketTimeout", "60000"); // 驱动类直接加载，不依赖DriverManager自动发现 try { Class.forName("com.mysql.cj.jdbc.Driver"); } catch (ClassNotFoundException e) { throw new RuntimeException("驱动类未找到，请检查依赖", e); } try (Connection conn = DriverManager.getConnection(url, props)) { System.out.println("连接成功，数据库产品名：" + conn.getMetaData().getDatabaseProductName()); } catch (SQLException e) { System.err.println("连接失败，错误码：" + e.getErrorCode()); e.printStackTrace(); } } }

这里有几个细节值得说明。Class.forName在JDBC 4.0之后其实可以省略，但显式保留的好处是：如果驱动jar缺失，会得到一个明确的ClassNotFoundException，而不是一个含糊的“找不到合适的驱动”的SQLException。排查问题的时候，错误信息越明确越好。connectTimeout和socketTimeout这两个参数，我强烈建议一定要配。connectTimeout限制的是建连阶段的等待时间，socketTimeout限制的是SQL执行过程中读响应的时间，不配的话，一旦网络抖动，线程会一直卡在底层的Socket读操作上，造成线程池被打满。

3.2 Statement、PreparedStatement和ResultSet的正确用法

拿到Connection之后，就是执行SQL。教科书会告诉你Statement和PreparedStatement都能执行SQL，但实际工作中，PreparedStatement是唯一应该用的选项。区别在于，PreparedStatement在数据库端会被预编译，SQL结构固定，参数用?占位符传递，既避免了字符串拼接的注入风险，又能在多次执行同一SQL时复用执行计划。

ResultSet是一个游标式的结果集，默认情况下只能向前遍历。用完之后一定要关闭，否则占用的数据库游标资源不会释放。try-with-resources会把ResultSet、Statement一起关掉，但注意关闭顺序：先关ResultSet，再关Statement，最后关Connection，try-with-resources正好按声明的逆序自动关闭。

还有一个日常很容易犯的错：拿到ResultSet之后，在ResultSet还没有关闭时去执行新的SQL。某些驱动实现里，同一个Connection上再次执行Statement会把上一个打开的ResultSet自动关掉，导致你后面的数据没读完就报错。真要在一个连接上连续执行多条SQL，最好先把上一批结果完整读进内存里的List，再执行下一条。

3.3 增删改查的标准写法与参数传递

写一个完整的增删改查示例，很多人觉得简单，但细节都在边界情况里。下面这段代码展示了查询和更新两种典型操作：

import java.sql.*; import java.time.LocalDateTime; import java.util.ArrayList; import java.util.List; public class CrudDemo { public record User(Long id, String name, Integer age, LocalDateTime createdAt) {} // 查询，注意使用try-with-resources public List<User> queryUsers(int minAge) throws SQLException { String sql = "SELECT id, name, age, created_at FROM t_user WHERE age >= ? ORDER BY id DESC"; List<User> users = new ArrayList<>(); try (Connection conn = getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setInt(1, minAge); // 参数下标从1开始，不是0 try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { // 游标逐行推进 User user = new User( rs.getLong("id"), rs.getString("name"), rs.getInt("age"), rs.getTimestamp("created_at").toLocalDateTime() ); users.add(user); } } } return users; } // 插入，并且返回自增主键 public Long insertUser(String name, int age) throws SQLException { String sql = "INSERT INTO t_user(name, age, created_at) VALUES(?, ?, NOW())"; try (Connection conn = getConnection(); PreparedStatement ps = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS)) { ps.setString(1, name); ps.setInt(2, age); int affected = ps.executeUpdate(); if (affected == 0) { throw new SQLException("插入失败，影响行数为0"); } try (ResultSet keys = ps.getGeneratedKeys()) { if (keys.next()) { return keys.getLong(1); } } throw new SQLException("未获取到自增主键"); } } private Connection getConnection() throws SQLException { String url = "jdbc:mysql://127.0.0.1:3306/demo_db" + "?useSSL=false&serverTimezone=Asia/Shanghai"; return DriverManager.getConnection(url, "app_user", "your_password"); } }

这段代码里有几个点需要特别强调。ps.setInt(1, minAge)的参数下标从1开始，不是0，这个错误频率出乎意料地高。ps.setTimestamp对应数据库的DATETIME/TIMESTAMP类型，如果你传的是java.util.Date，驱动也能处理，但最好统一用java.sql.Timestamp或LocalDateTime（配合JDBC 4.2的setObject）。插入时传Statement.RETURN_GENERATED_KEYS是拿自增主键的标准姿势，如果你不加这个参数，直接执行insert之后再去查getGeneratedKeys()大概率返回空。

还有一个细节：executeUpdate的返回值是受影响的行数，更新和删除操作都应该检查这个返回值，如果为0，说明你要操作的数据根本不存在，或者已经被并发修改了，这时候应该抛异常，而不是静默通过。

4. 连接失败、时区错乱、连接池耗尽：高频故障排查实录

4.1 从ClassNotFoundException到CommunicationsException

连接数据库报错的信息五花八门，但归根结底可以归成几类，每一类的排查路径都不一样。

如果报ClassNotFoundException: com.mysql.cj.jdbc.Driver，说明驱动jar没在classpath里。用Maven的话检查依赖坐标对不对，用传统方式部署的话检查lib目录下有没有jar。这里有个高级坑：一个Tomcat里部署多个应用，每个应用的lib是隔离的，你把驱动放到了Tomcat的lib还是应用自己的lib，类加载路径完全不同。放错位置会导致某些应用能连，某些不能连。

如果报No suitable driver found for jdbc:mysql://...，说明DriverManager里没有匹配URL前缀的驱动。可能原因包括：驱动jar没加载成功、URL协议头写错、用了DriverManager但驱动是通过ServiceLoader加载失败。排查时可以手动执行Class.forName，如果这行能过，大概率是URL前缀问题。

如果报CommunicationsException: Communications link failure，这是MySQL驱动对底层Socket异常的统一包装。它可能是网络不通、端口被封、防火墙拦截、MySQL服务挂了，也可能是驱动和数据库版本不兼容。排查路径应该是：先telnet 数据库IP 3306看看端口通不通，再确认数据库服务进程是否存活，最后看MySQL的错误日志。大部分时候，这个问题跟应用代码没关系，是环境问题。

每次拿到异常别急着Google，先把完整堆栈读一遍。SQLException的message通常很长，里面会包含驱动版本、服务器版本、具体出错环节（比如during handshake还是during query）。根据出错环节能快速定位是建连阶段还是执行阶段的问题。

4.2 时区、SSL和连接超时这三兄弟

这三个问题几乎是MySQL 8连接初期最常见的三个坑。我列一张对照表，方便你按症状排查：

报错或异常现象	根因	解决方案
The server time zone value ' CST' is unrecognized	驱动无法识别数据库会话时区	URL加serverTimezone=Asia/Shanghai
查询出的时间比数据库实际时间少8小时或多8小时	JVM时区和数据库时区不一致	统一设置连接时区和JVM时区
SSLConnectionException或SSL握手失败	驱动默认启用SSL但服务端没配证书	URL加useSSL=false或sslMode=DISABLED
Public Key Retrieval is not allowed	MySQL 8默认认证插件需要公钥	URL加allowPublicKeyRetrieval=true
Connection is not available, request timed out	连接池等待超时	检查慢SQL、增大池上限、缩短connectionTimeout
半夜过后第一次请求必报连接错误	连接空闲超过数据库wait_timeout	配置连接池maxLifetime和空闲检测

时区这个问题我多解释一句。数据库存的TIMESTAMP是不带时区的，MySQL驱动在读取时会把它解释成服务器时区下的时间，然后转成Java的Timestamp对象。如果服务器时区是UTC，JVM时区是Asia/Shanghai，最终打印出来的时间就会差8小时。解决思路是让“数据库会话时区、驱动转换时区、JVM解析时区”三者保持一致，最省事的做法是全部统一成Asia/Shanghai。

SSL这块，内网环境默认useSSL=false是安全的，因为内网流量一般不走公网。但如果你连的是云数据库公网地址，建议反着来，useSSL=true并配置服务器证书，防止账号密码和查询数据在链路上被截获。安全不是一刀切，看场景。

连接超时的排查则需要联系DBA一起看。数据库没挂但连接池耗尽的情况，通常意味着有慢查询占着连接不释放，或者有连接泄漏没归还。先看慢查询日志，再查应用的连接池监控，Druid和HikariCP都有现成的监控指标，看看active连接数、等待线程数，能很快定位是池子太小还是SQL太慢。

4.3 一套屡试不爽的连接问题排查顺序

排查JDBC连接问题，我建议按这个顺序来，避免像无头苍蝇一样乱试。

第一步，把完整异常信息和控制台输出的所有日志贴出来，包括Caused by部分。很多时候真正的根因在Caused by里，而不在最外面的message里。第二步，确认驱动版本、数据库版本、JDK版本三者兼容，去驱动官方文档看支持的矩阵。第三步，用一个最简单的测试类，只做DriverManager.getConnection，排除业务代码干扰。如果这一步成功，问题在业务层；失败，问题在环境或配置。第四步，用数据库自己的客户端（比如mysql命令行）去连，确认数据库本身服务正常。如果命令行能连而JDBC不能连，重点检查驱动参数，比如认证插件、SSL、公钥获取。第五步，抓包看TCP层，确认连接请求有没有到达数据库。

这套流程跑下来，90%的问题在第三步就能定位。剩下10%属于数据库配置层面的边边角角，比如max_connections打满、skip-networking开启、账号host限制不匹配等，这些需要结合数据库侧的状态变量看。

5. 从单连接走向连接池，生产环境的正确姿势

5.1 为什么必须用连接池，以及HikariCP参数怎么配

有人说，我用上面的代码，每次执行SQL都新建一个Connection不行吗？技术上能跑，但生产环境不该这么干。建连的成本包含TCP三次握手、MySQL认证握手、初始化会话变量，整套流程下来少说几十毫秒，高并发下这个开销直接变成系统的瓶颈。更重要的是，数据库对并发连接数是有限制的，max_connections默认151，单机应用每个请求新建连接，压力一上来，数据库的连接数瞬间被打满。

连接池的核心思路是预先创建一批连接，放在池子里，应用需要时借出、用完归还，所有权在池子手里。这样建连开销只发生一次，后续都是复用。

HikariCP是当前性能最好的连接池，Spring Boot 2.x以后默认就是它。它的参数配置看着简单，但有几个值需要认真调：

HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://127.0.0.1:3306/demo_db?useSSL=false&serverTimezone=Asia/Shanghai"); config.setUsername("app_user"); config.setPassword("your_password"); config.setDriverClassName("com.mysql.cj.jdbc.Driver"); config.setMaximumPoolSize(20); config.setMinimumIdle(5); config.setConnectionTimeout(5000); config.setIdleTimeout(600000); config.setMaxLifetime(1800000); config.setConnectionTestQuery("SELECT 1"); HikariDataSource dataSource = new HikariDataSource(config);

maximumPoolSize的公式在HikariCP官方文档里有：connections = ((core_count * 2) + effective_spindle_count)。但我觉得实践里更重要的口径是：峰值并发请求数除以单连接能撑起的请求数，再留20%冗余。设置过大的池子没用，连接是数据库侧的稀有资源，池子再大，数据库连接数上限卡死，等待时间反而更长。

maxLifetime必须小于数据库的wait_timeout，前面已经提过。connectionTestQuery的作用是借出连接时测试存活，但HikariCP官方文档说，如果你用了JDBC4的Connection.isValid()，这个参数可以不配。MySQL的驱动原生支持isValid，所以一般不用额外配test query。

5.2 把连接池接进Spring Boot，以及DataSource的正确打开方式

Spring Boot里配置HikariCP非常顺滑，因为框架已经内置了。你只需要在application.yml里写：

spring: datasource: url: jdbc:mysql://127.0.0.1:3306/demo_db?useSSL=false&serverTimezone=Asia/Shanghai username: app_user password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 5000 idle-timeout: 600000 max-lifetime: 1800000

但是这里有一个非常关键的坑：很多人以为数据源配置好了，Spring会自动帮我们把事务和连接管理全部搞定，于是干脆不关心底层连接的事情。结果线上出现“获取连接超时”的时候，根本不知道从哪里下手。我建议即使你用Spring Boot，也要理解底层的执行链：Controller调用Service，Service方法上的@Transactional注解会让Spring在方法开始前从DataSource获取一个连接，绑定到当前线程，方法内所有DAO操作共用这个连接，方法结束后归还。一旦方法内部有慢SQL，这个连接被占住的时间就是整个事务的时长，并发一高，池子就容易被耗尽。

还有一个容易被忽略的点：@Transactional的rollbackFor默认只对RuntimeException和Error生效。如果你在事务方法里抛了一个自定义的checked异常，事务不会回滚，数据会处于半提交状态。这个跟连接管理无关，但却是事务使用中最常踩的坑，一并提醒。

6. 事务边界和批处理，连接之外的进阶必修课

6.1 在JDBC层面理解ACID的落点

连接拿到手之后，事务就是下一个必须掌握的概念。默认情况下，Connection处于自动提交模式，每执行一条SQL就提交一次。但业务往往要求多条SQL要么全部成功，要么全部失败，这时候就要关掉自动提交，手动控制事务边界。标准写法是这样：

try (Connection conn = getConnection()) { conn.setAutoCommit(false); // 关闭自动提交 try { try (PreparedStatement ps1 = conn.prepareStatement( "UPDATE t_account SET balance = balance - ? WHERE id = ?")) { ps1.setBigDecimal(1, new BigDecimal("100.00")); ps1.setLong(2, 1001L); ps1.executeUpdate(); } try (PreparedStatement ps2 = conn.prepareStatement( "UPDATE t_account SET balance = balance + ? WHERE id = ?")) { ps2.setBigDecimal(1, new BigDecimal("100.00")); ps2.setLong(2, 1002L); ps2.executeUpdate(); } conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } }

事务的隔离级别也是连接级别的重要属性。MySQL默认是REPEATABLE_READ，PostgreSQL默认是READ_COMMITTED。如果你在一个事务里对同一条数据先查询后更新，又希望查询结果和更新后的结果一致，要注意快照读和当前读的区别。练习阶段不用深究，但在并发业务中，SELECT ... FOR UPDATE和普通SELECT的行为差异会直接影响业务正确性，这个可以之后单独写一篇深入展开。

另外，事务和连接池配合时要记住：连接归还到池子之前，事务状态必须被清理。HikariCP会在连接归还时自动rollback未提交的事务并恢复autoCommit默认值，避免污染下一个使用者。但如果你用的是自己管理的连接，务必在finally里处理，否则一个连接残留的未提交事务，会让下一个拿到该连接的操作看到脏数据，或者干脆锁死相关行。

6.2 批量插入为什么能快一个数量级

批量处理是JDBC里见效最明显的优化手段之一。比如要往一个表里插入一万条数据，一条一条executeUpdate，每条都走一次网络往返，耗时可能几十秒。用批量提交，性能提升一个数量级不止。

public void batchInsert(List<User> users) throws SQLException { String sql = "INSERT INTO t_user(name, age, created_at) VALUES(?, ?, NOW())"; try (Connection conn = getConnection()) { conn.setAutoCommit(false); try (PreparedStatement ps = conn.prepareStatement(sql)) { for (User user : users) { ps.setString(1, user.name()); ps.setInt(2, user.age()); ps.addBatch(); // 加入批量队列 // 每500条执行一次，避免batch太大占用过多内存 if (users.size() % 500 == 0) { ps.executeBatch(); conn.commit(); } } ps.executeBatch(); // 执行剩余批次 conn.commit(); } catch (SQLException e) { conn.rollback(); throw e; } } }

批量提交能快，是因为减少了客户端和数据库之间的网络交互次数，同时数据库侧可以连续处理多条插入。但要注意rewriteBatchedStatements=true这个MySQL驱动的URL参数，没加它之前，驱动会把批量SQL拆成一条一条发给服务器，加了之后，驱动会把多条INSERT重写成一条多值的INSERT，性能进一步提升。这个参数值得在批量场景下专门加上。

批量操作还有一个很隐蔽的坑：executeBatch如果其中一条失败，整个批次的状态会因为驱动不同而不同，有的驱动会把批次全部回滚，有的会保留成功的部分。建议设置rewriteBatchedStatements=true之后，在事务里执行批量，并且对影响行数求和做校验，不一致就报错。

7. 我在实际项目中沉淀的几条连接管理经验

最后分享几点真正经历过生产环境考验的经验，这些细节不写进官方文档，但往往能救命。

第一，连接字符串永远不要硬编码在代码里。就算现在是个人项目，也应该走配置中心或环境变量。我见过同事把带密码的JDBC URL直接提交到Git仓库，然后被扫描工具报警的事，改密码、清历史，折腾了一下午。

第二，数据库密码不要用明文存储在配置文件中。至少用Jasypt之类的组件做加密，密钥放在部署环境变量里。云厂商的数据库服务一般都支持类似KMS的密钥管理，能用就用，成本很低。

第三，给连接池加上监控告警。HikariCP的指标可以暴露到Micrometer，接入Prometheus之后，对“活跃连接数”、“等待获取连接线程数”、“连接创建数”三个指标设置阈值告警。数据库连接问题很少直接导致宕机，更多是默默拖慢应用，等你发现的时候，系统已经卡了半小时。

第四，在应用启动时做一次连接自检。比如Spring Boot的ApplicationRunner里从连接池拿一个连接执行SELECT 1，成功才继续启动，失败直接fail-fast。这样配置问题在发布阶段暴露，而不是等服务上线后，第一个请求进来才炸。

第五，定期阅读驱动升级日志。数据库驱动不是越新越好，但也不能一个版本用到天荒地老。MySQL的驱动偶尔会调整默认行为，比如某个小版本把useSSL默认值从false改成true，或者把时区处理逻辑改了，升级前多看一眼release notes，性价比极高。

JDBC连接数据库这件事，写代码五分钟，调参两小时，排查一整天。但正因为这些坑都踩过一遍，你才能对Java访问数据库这条链路有真正的掌控感。希望这篇内容能帮你少走几次弯路，下次再遇到连接问题，先稳住，按步骤来，问题会比你想象中更快现出原形。