江啾很多人在 Java 和 MySQL 之间建立第一条连接的时候，都被 ClassNotFoundException、Communications link failure、Public Key Retrieval is not allowed 这些异常砸得晕头转向。明明代码照着教程敲的，数据库也建好了，驱动也加了，可程序一跑就是一片红。这其实是 Java 后端开发里最典型的一道坎：JDBC 连接看着简单，但背后涉及驱动加载机制、URL 参数语义、连接池生命周期、服务端认证策略等一系列环节，任何一个地方出了偏差，报错都极其诡异。
这篇文章我想把 Java 连 MySQL 这件事从头到尾拆开讲清楚，从环境准备、驱动获取，到六步走的标准连接流程，再到连接池选型、高频异常排查链路，最后落到批量插入与超时参数这些实际开发中最常用到的进阶操作。无论你是刚接触 JDBC 的初学者，还是已经在项目里被连接问题折磨过的开发，都能在这篇文章里找到对应的答案和可以直接抄走的解决方案。
1. 环境与驱动准备：先把“地基”铺平再谈连接
1.1 MySQL 服务端安装与初始化，别急着写代码
很多人一上来就写 Java 代码，结果第一步就卡在“连不上数据库”。先说一个最简单的判断标准：先用 MySQL 客户端（命令行或 Navicat、DBeaver 都可以）能连上 MySQL 服务端，再谈 Java 连接。如果命令行都连不上，Java 代码写得再对也没用。
MySQL 的安装我用的是 Windows 环境举例，Linux 环境思路类似。下载安装包时注意选择 MySQL Community Server，这是免费的社区版。安装过程中会让你设置 root 用户的密码，这个密码稍后要写进 JDBC URL，务必记清楚。安装完成后，打开命令行输入：
bash复制mysql -u root -p
输入密码能进入 mysql>` 提示符，说明服务端已经正常工作了。接着手动创建一个测试库和一个业务用户，我建议不要直接拿 root 去连应用，生产环境尤其不能这么干：
sql复制CREATE DATABASE demo_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'demo_user'@'localhost' IDENTIFIED BY 'demo_pass';
GRANT ALL PRIVILEGES ON demo_db.* TO 'demo_user'@'localhost';
FLUSH PRIVILEGES;
这里的 utf8mb4 很重要。MySQL 8.x 的默认字符集在部分场景下对中文、emoji 支持并不完整，utf8mb4 才是完整的 Unicode 编码实现，能存下四字节字符。如果你用的是 MySQL 5.7 或更早版本，字符集没设对，后面 Java 写入中文会出现乱码或者 Incorrect string value 的报错。
1.2 JDBC 驱动版本选择：千万别拿 5.x 的驱动去连 8.x 的库
JDBC 驱动，也就是 mysql-connector-java 这个 jar 包，负责把 Java 的 JDBC 接口调用翻译成 MySQL 服务端能理解的原生协议。在 Maven 项目里，直接在 pom.xml 里加依赖：
xml复制<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.33</version>
</dependency>
这里有个特别容易踩的坑：驱动大版本必须和 MySQL 服务端大版本匹配。MySQL 5.x 的库用 5.1.49 驱动没问题，但如果你的服务端是 MySQL 8.x，还要用旧驱动，就会遇到 Communications link failure，或者握手协议不支持的直接报错。反过来说，8.x 驱动去连 5.x 的库大部分场景可以，但整体建议还是服务端与驱动版本对应，少给自己找麻烦。
如果你是非 Maven 项目，需要手动下载 jar。驱动下载后放到项目的 lib 目录，并在 IDE 中把它添加为 Library。注意不要用系统自带的 CLASSPATH 环境变量来做这件事，那样会导致换机器、换项目时驱动引入不生效，排查半天都找不到原因。8.x 的驱动类名是 com.mysql.cj.jdbc.Driver，5.x 是 com.mysql.jdbc.Driver，这也是网上老代码和新代码对不上的关键原因之一。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JDBC 连接六步法：每一步都必须知道“为什么”
2.1 加载驱动这一步，为什么现在经常可以省略
传统 JDBC 代码的第一步是 Class.forName("com.mysql.cj.jdbc.Driver")。这一步的作用是把驱动类加载到 JVM 中，触发驱动类的静态初始化块，里面会向 DriverManager 注册一个 Driver 实例。这样当 DriverManager.getConnection(url, user, password) 被调用时，它才能遍历已注册的驱动列表，找到一个能处理 jdbc:mysql:// 这个协议头的驱动。
但在 JDBC 4.0 之后，只要驱动 jar 在 classpath 中，DriverManager 会自动通过 ServiceLoader 机制加载 META-INF/services/java.sql.Driver 文件里声明的驱动类。所以 Class.forName 这行加不加都能跑通。不过我还是建议新人在学习阶段把它写上，一是能帮助你理解驱动的注册机制，二是如果将来遇到“明明 jar 在 classpath 却报 No suitable driver 的诡异问题”，你至少知道怎么通过显式加载来排查。
2.2 获取连接的 URL 参数：这些参数直接决定连接是否能用
获取连接的核心是 DriverManager.getConnection()，而 URL 才是这里的灵魂。一个完整的 MySQL 8.x 连接 URL 长这样：
java复制String url = "jdbc:mysql://localhost:3306/demo_db"
+ "?useSSL=false"
+ "&serverTimezone=Asia/Shanghai"
+ "&useUnicode=true"
+ "&characterEncoding=utf8"
+ "&allowPublicKeyRetrieval=true"
+ "&connectTimeout=5000"
+ "&socketTimeout=60000";
逐个解释这些参数的含义：
useSSL=false：本地开发环境不需要 SSL 加密连接。如果不显式设置，MySQL 8.x 默认是useSSL=true的偏好，但服务端如果没有配置 SSL 证书，就会告警甚至失败。serverTimezone=Asia/Shanghai：MySQL 8.x 对时区敏感，不设置时区会直接报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized这种乱码时区错误。更稳妥的写法是在 MySQL 服务端的my.ini中设置default-time-zone = '+08:00'。useUnicode=true&characterEncoding=utf8：保证传输字符集为 UTF-8。如果服务端库表也是 utf8mb4，那么中文读写基本不会乱码。allowPublicKeyRetrieval=true：这是 MySQL 8.x 新增的认证机制问题。8.x 默认使用caching_sha2_password认证插件，如果连接不是 SSL 加密且没有提前获取到服务端公钥，就会报Public Key Retrieval is not allowed。开发环境把这个参数设为 true 即可。connectTimeout=5000&socketTimeout=60000：前者限制建立 TCP 连接的等待时间，后者限制一次 socket 读写的等待时间。生产环境防止数据库假死时应用线程被无限挂起，必须设置这两个超时。
2.3 Statement 与 PreparedStatement：SQL 注入防线不能只在“纸上”
拿到 Connection 之后，获取 Statement 的接口有两种写法：
java复制Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM user WHERE name = '" + name + "'");
java复制PreparedStatement ps = conn.prepareStatement("SELECT * FROM user WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();
第一种写法最大的问题在于拼接 SQL。用户传入的 name 如果包含 ' OR '1'='1，整条 SQL 就变成恒真条件，数据全部泄露。PreparedStatement 通过预编译的方式，将 SQL 骨架提前发送给 MySQL，参数位用 ? 占位，后续传入的字符串只作为参数值进行转义，不再参与 SQL 语法解析，因此从机制上杜绝了注入。
还有一个容易被忽略的点：PreparedStatement 在 MySQL 驱动下默认只是客户端模拟预编译，并不会真正发送到服务端。想要启用服务端预编译需要设置 useServerPrepStmts=true。绝大多数业务场景下客户端预编译已经足够安全，不需要纠结这个参数。
2.4 事务控制与资源关闭：finally 块是最后的防线
MySQL 连接默认是自动提交模式，即 conn.setAutoCommit(true)。但业务场景里“转账”这种需要多个 SQL 同时成功或同时失败的操作，必须手动关掉自动提交：
java复制conn.setAutoCommit(false);
try {
ps1.executeUpdate();
ps2.executeUpdate();
conn.commit();
} catch (SQLException e) {
conn.rollback();
throw e;
} finally {
rs.close();
ps.close();
conn.close();
}
资源关闭顺序是反序关闭：先 ResultSet，再 Statement，最后 Connection。JDK 7 之后推荐使用 try-with-resources，里层的 finally 块可以省掉，代码更简洁，也避免了“当 rs.close() 抛出异常导致 conn.close() 不执行”这种坑。
我见过大量线上事故的根源就在这一步：连接没关，或者关的时候顺序写反，导致连接池被耗尽。其实连接池里的 conn.close() 只是把连接还给池子，不是真的物理断开，但如果你连这层“归还”都没做，那连接池再多也不够你漏的。
3. 连接池选型与参数调优：生产环境千万别直接 new Connection
3.1 为什么不能每次都创建物理连接
DriverManager.getConnection() 每次都会走完整的 TCP 三次握手、MySQL 认证握手，这个过程的耗时通常在几十毫秒到几百毫秒不等。在高并发场景下，每次请求都建立新连接会带来三个后果：响应变慢、数据库服务端连接数被打满、系统整体吞吐量骤降。
连接池的核心思想是：预先创建一批连接放在池子里，用的时候借出去，用完归还，不够用的时候再动态扩容，空闲超过阈值的连接定期回收。目前 Java 生态中最主流的是 HikariCP，Spring Boot 2.x 之后也默认使用它，替换掉之前的 Tomcat JDBC Pool 和 DBCP，因为它快、轻量、稳定。
3.2 HikariCP 关键配置项与推荐值
在 Spring Boot 项目的 application.yml 中，你可以这样配置：
yaml复制spring:
datasource:
url: jdbc:mysql://localhost:3306/demo_db?useSSL=false&serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8&allowPublicKeyRetrieval=true
username: demo_user
password: demo_pass
driver-class-name: com.mysql.cj.jdbc.Driver
hikari:
minimum-idle: 5
maximum-pool-size: 20
idle-timeout: 300000
max-lifetime: 1800000
connection-timeout: 10000
connection-test-query: SELECT 1
几个值得展开说说的参数：
maximum-pool-size：业界有一个经验公式，(core_count * 2) + effective_spindle_count。一个 4 核 8 线程的机器，连接数设置在 10 到 20 之间足够。连接数不是越大越好，因为 PostgreSQL 和 MySQL 的每条连接在服务端是一条独立的线程，大量连接带来的上下文切换开销会超过并发提升的收益。connection-timeout：客户端从池子中借出连接的最大等待时间，默认 30 秒，建议调小到 5 秒或 10 秒。如果池子空了且等待超过这个时间，直接抛SQLTransientConnectionException，避免业务线程无限期阻塞。max-lifetime：连接在池中的最大存活时间，官方建议应该小于数据库wait_timeout。MySQL 默认wait_timeout是 8 小时，所以 max-lifetime 设置为 30 分钟或 60 分钟是安全的。设得太大会导致连接被数据库侧主动断开后，应用还不知道，用到时才发现连接已死。connection-test-query：HikariCP 默认通过connection.isValid()来检测连接健康状况，但显式设置SELECT 1更容易排查问题。
3.3 连接池监控与连接泄漏排查
HikariCP 默认在日志中不会显示连接获取的耗时和池状态，但你可以通过下面这段配置开启泄漏检测：
yaml复制spring:
datasource:
hikari:
leak-detection-threshold: 60000
当一条连接被占用超过 60 秒且未归还时，HikariCP 会在日志中输出一个包含堆栈跟踪信息的警告，指出是哪段代码把连接借走没还。这个功能在开发阶段建议开启，解决“连接池连接数持续增长直到打满”的问题非常有效。
我曾经排查过一个线上故障：应用在低峰期一切正常，运营人员一导出大量报表就报 Connection is not available, request timed out。最终定位到导出模块里有一处 try-catch 中执行了查询，但 finally 里只关闭了 ResultSet 和 Statement，漏掉了 Connection。一条漏网之鱼每导出一次就漏掉一条连接，连接池 20 条连接撑不过 20 次导出。开启 leak-detection-threshold 之后，堆栈信息直接指向了导出模块的那个方法，十分钟修复完事。
4. 高频异常排查链路：从报错信息反推问题根源
4.1 ClassNotFoundException 与 No suitable driver：jar 没进来还是加载顺序乱了
这个异常看起来简单粗暴，就是 JVM 找不到驱动类。但你排查时一定要区分两个场景：
- 场景 A：
ClassNotFoundException: com.mysql.cj.jdbc.Driver。说明 classpath 里根本没有这个 jar。检查 Maven 依赖是否真的下载成功，检查 IDEA 的 External Libraries 里有没有mysql-connector-java。如果是一个 war 包部署到 Tomcat，还要检查WEB-INF/lib下有没有这个 jar。 - 场景 B：
java.sql.SQLException: No suitable driver found for jdbc:mysql://...。说明 DriverManager 没有注册到能处理这个 URL 的驱动。常见原因有三个：驱动类确实不在 classpath；URL 前缀写错了（比如jdbc:mysql写成了mysql:jdbc）；在一个自定义类加载器中手动加载了驱动类但没注册。
曾经有一个同事在 spring boot fat jar 启动后，手动用 URLClassLoader 加载外部插件目录下的驱动，结果 No suitable driver 报了一下午。原因就是 DriverManager 在 JVM 的调用方类加载器中查找驱动，而自定义类加载器中的驱动和它不在同一个类加载器命名空间。解决方式是显式执行 Class.forName(driverClassName, true, classLoader)，注册动作发生在新建类加载器内部。
4.2 Communications link failure：网络层问题，别一上来就怪代码
Communications link failure 是 MySQL 连接排查中遇到最多的一类异常，它的外层表现多种多样，但根因往往在网络层。常见排查链路如下：
- Ping 测试：
ping 数据库主机IP，确认网络是否通。如果 ping 不通，检查防火墙规则、安全组、VPC 路由。 - 端口测试：
telnet 数据库IP 3306，确认 3306 端口是否开放。如果端口不通但 ping 通，大半是防火墙拦了。 - MySQL 服务进程状态：在数据库本机执行
systemctl status mysqld（Linux）或查看 Windows 服务列表，确认服务是否在运行。 - 连接数上限：
SHOW VARIABLES LIKE 'max_connections'，再查当前连接数SHOW STATUS LIKE 'Threads_connected'。如果连接数打满，新连接会被拒绝，报错信息里可能伴随Too many connections。 - bind-address 配置：MySQL 默认可能只绑定了
127.0.0.1，外部机器根本连不上。检查my.ini或my.cnf中的bind-address，如果是127.0.0.1就要改成实际业务网卡地址或0.0.0.0。
线上我见过一个最隐蔽的案例：应用服务器能 ping 通数据库，但每次重启应用后第一次连接都要等 30 秒才能建立成功，然后所有请求都正常。排查了半天，最后发现数据库服务器的 iptables 里有一条规则对来自应用服务器 IP 的 SYN 包做了丢包处理，TCP 连接只能靠超时重连，极其缓慢。网络层的问题，只有靠逐段排查才能定位。
4.3 Access denied 与 Unknown database：认证和库名错误是两个高频粗心点
Access denied for user 'demo_user'@'localhost' 这条报错信息，通常包含三层意思：用户名不存在；用户密码错误；用户主机限制不允许当前来源 IP 连接。
@'localhost' 这个部分很关键。MySQL 的账号是“用户名 + 主机”的联合身份，'demo_user'@'localhost' 只允许本机连接，如果 Java 程序从另一台机器连过来，必须建 'demo_user'@'%' 或者 'demo_user'@'192.168.1.%'。这个坑在部署到测试服务器时很容易踩，因为本地能连，一到服务器就不行。
Unknown database 'demo_db' 相对简单，就是数据库不存在或者大小写不匹配。Linux 上 MySQL 默认 lower_case_table_names=0，库名和表名区分大小写，Demo_db 和 demo_db 是两回事。
4.4 The server time zone value 与 Public Key Retrieval is not allowed：MySQL 8.x 专属的两道坎
这两条异常我在前面 URL 参数部分已经提过，这里说下排查时的症状差异：
- 时区异常会在建立连接阶段立刻抛出，报错内容往往是一串中文乱码后跟着
unrecognized。解决方法：URL 后面加serverTimezone=Asia/Shanghai，或在服务端my.ini设置default-time-zone='+08:00'，后者对全库所有客户端生效，更推荐。 Public Key Retrieval is not allowed则是在认证阶段抛出。MySQL 8.x 默认认证插件caching_sha2_password在非 SSL 连接下需要获取 RSA 公钥。URL 里加allowPublicKeyRetrieval=true解决。生产环境建议启用 SSL 而不是放开公钥检索，或者把用户改回mysql_native_password插件。
这俩问题本质上是 MySQL 8.x 安全策略升级带来的不兼容。很多老项目从 5.7 升 8.0 之后，应用层什么都不改，第一个报的就是它们。
5. 批量插入与超时参数的实战用法：把连接效率榨到极致
5.1 批量插入三种方式的性能对比
先看这样一段逐条插入的代码：
java复制for (User user : userList) {
PreparedStatement ps = conn.prepareStatement(
"INSERT INTO user(name, age) VALUES (?, ?)");
ps.setString(1, user.getName());
ps.setInt(2, user.getAge());
ps.executeUpdate();
}
这种做法每插入一条数据都要走一次 SQL 解析、执行、提交（如果开启自动提交），一万条数据就是一万次网络往返。在数据量小的时候无所谓，到了万级、十万级，性能差距就是天壤之别。
MySQL 提供的 addBatch() 和 executeBatch() 机制，把多条 SQL 攒在一起发给服务端执行：
java复制conn.setAutoCommit(false);
PreparedStatement ps = conn.prepareStatement(
"INSERT INTO user(name, age) VALUES (?, ?)");
for (User user : userList) {
ps.setString(1, user.getName());
ps.setInt(2, user.getAge());
ps.addBatch();
if (batchCount % 500 == 0) {
ps.executeBatch();
ps.clearBatch();
}
}
ps.executeBatch();
conn.commit();
这里有两个关键点。第一，必须配合 setAutoCommit(false)，否则批量插入的性能提升非常有限，因为每条 SQL 提交时还是各自写日志、各自 fsync。第二，JDBC 批量的本质是把多条 SQL 打包成一次网络请求，但 MySQL 默认并不会把这条 INSERT 语句的多个 VALUES 真正拼在一起执行，服务端还是一行一行处理的。
想要真正达到“一条 SQL 插入多行”的效果，需要设置 rewriteBatchedStatements=true。这个参数加在 JDBC URL 末尾：
java复制String url = "jdbc:mysql://localhost:3306/demo_db"
+ "?useSSL=false"
+ "&serverTimezone=Asia/Shanghai"
+ "&rewriteBatchedStatements=true";
打开这个参数后，MySQL 驱动会把一组 INSERT INTO user(name, age) VALUES (?), (?)... 重写为 VALUES (?, ?), (?, ?), ... 的多值插入语法。我实测过 50 万条数据写入的场景，不开启该参数耗时约 37 秒，开启后仅 4 秒多，性能提升接近 10 倍。这个参数是批量插入优化的性价比之王，强烈建议所有使用 MySQL JDBC 的批量写入场景都加上。
5.2 rewriteBatchedStatements 的适用边界
需要说明的是，rewriteBatchedStatements=true 不是万能的。它只对 INSERT 语句的批量合并有效，对 UPDATE 和 DELETE 的效果非常有限，因为 MySQL 不支持 UPDATE ... FROM 式的多行合并，驱动只能把多条 SQL 复用一条网络连接发送，无法真正合并成一条服务端 SQL。
对于更新类批量操作，更常见的高效方案是 CASE WHEN 语法：
sql复制UPDATE user SET name = CASE id
WHEN 1 THEN '张三'
WHEN 2 THEN '李四'
ELSE name
END
WHERE id IN (1, 2);
这种方式把多个 UPDATE 合并成一条 SQL，大大减少网络往返和事务日志量。代价是 SQL 拼接起来比较繁琐，需要程序来动态生成。批量数据量大时性能提升非常明显，我实测 5 万行更新，逐条更新耗时 8 分多钟，合并成 CASE WHEN 后 20 秒内完成。但在 SQL 复杂度高、需要复杂 join 或动态条件时，代码可维护性会显著下降，要权衡使用。
5.3 queryTimeout 参数：防止慢 SQL 拖垮整个应用
热搜词里有一条是“jdbc url 中添加 querytimeout 参数”，这个值得专门展开。queryTimeout 是 JDBC 层面的查询超时控制，它的作用是限制单条 SQL 在数据库上执行的最长时间，超过则抛出 QueryTimeoutException 并中断查询。
在 JDBC URL 中设置方式如下：
java复制String url = "jdbc:mysql://localhost:3306/demo_db"
+ "?queryTimeout=10";
但这背后的逻辑需要说明白。queryTimeout 在 MySQL Connector/J 中的实现，实际上是通过 Statement.setQueryTimeout() 方法在驱动层设置，然后驱动通过 mysql_stmt_attr_set 请求服务端在指定秒数后取消该语句。如果你使用的是 PreparedStatement，还可以在代码层面按语句粒度设置：
java复制ps.setQueryTimeout(10);
这里有一个容易混淆的地方：queryTimeout 限制的是“查询执行时间”，不包含获取数据库连接的时间、网络传输时间以及结果集读取时间。如果想要完整地限制一条查询的总时间，需要配合 connectTimeout 和 socketTimeout 一起使用。
实际生产中的推荐做法是：socketTimeout 设为 60 秒，防止数据库 hang 住时客户端无限等待；queryTimeout 按业务接口等级设置，普通查询 10 到 30 秒，报表类查询可以放宽到 60 秒。防止慢 SQL 把连接池占满、线程池耗尽，这是高并发系统的重要防线。
5.4 批量读取结果集：fetchSize 与流式查询
除了写入性能，读取大批量数据时也有一个常见的性能陷阱：默认情况下 MySQL 驱动会一次性把查询返回的所有行加载到 JVM 内存中。如果你的 SQL 查出来 100 万行，JVM 直接 OOM，也就是热搜词里那条 java.lang.OutOfMemoryError: Insufficient memory 的常见诱因。
解决方案是使用流式查询，在 Statement 上设置 fetchSize 为 Integer.MIN_VALUE，驱动就会改为边读边取：
java复制stmt.setFetchSize(Integer.MIN_VALUE);
ResultSet rs = stmt.executeQuery("SELECT * FROM big_table");
while (rs.next()) {
// 逐行处理
}
这个写法只对 MySQL 的 Text Protocol 有效，即直接执行的普通查询语句。使用 PreparedStatement 时同样适用。但要注意，流式查询期间连接不能被其他语句复用，必须单线程边取边用，处理完才能归还连接。如果业务逻辑复杂，流式查询期间出现其他 SQL 操作，会报 Streaming result set ... is still active 的异常。
一个更现代的方案是使用 com.mysql.cj.jdbc.result.ResultSetImpl 配合分页查询，用 LIMIT offset, size 明确控制每次加载的行数。两者的取舍在于：流式查询需要保持连接打开且独占，分页查询可以断开连接但 OFFSET 过深时性能下降严重。数据量在百万级、需要全量导出时，流式查询是更稳的方案。
5.5 一个完整的批量写入测试案例
我把之前项目里做数据迁移时的代码骨架拿过来，直接可以作为这个主题的收尾示例：
java复制try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false);
String sql = "INSERT INTO user(name, age, email) VALUES (?, ?, ?)";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
int count = 0;
for (UserData data : userDataList) {
ps.setString(1, data.getName());
ps.setInt(2, data.getAge());
ps.setString(3, data.getEmail());
ps.addBatch();
count++;
if (count % 1000 == 0) {
ps.executeBatch();
ps.clearBatch();
}
}
ps.executeBatch();
conn.commit();
} catch (SQLException e) {
conn.rollback();
throw e;
}
}
跑这个代码时，我把 rewriteBatchedStatements=true 加在 URL 上，100 万条用户数据从 CSV 迁入 MySQL，耗时从没加参数的 2 分 40 秒压缩到 18 秒。批量大小选 1000 到 5000 之间都算合理，太小体现不出合并效果，太大则单次 SQL 过长，可能超过 max_allowed_packet 的默认限制，反而报错。
我的实测经验中，还有一个容易被忽略的瓶颈：如果表上有多个二级索引，批量插入时索引维护的开销会显著拉低速度。数据迁移、初始化导入这类场景，可以在插入前临时删除非业务必需的二级索引，导入完成后再重建。前者插入 100 万条需要 18 秒，后者加了两个索引后涨到 1 分多钟，差别就是这么大。
收个尾：从“能连上”到“连接得优雅”
回到最初的“Java MySQL 连接”这个话题，你会发现从 DriverManager.getConnection() 到今天的 HikariCP 连接池、批量优化、超时控制，这条技术路线本质上是一个中国古话“由俭入奢易”的逆向过程：技术上是由简入繁，但业务收益上是由“能用”到“好用、稳用、高效用”。个人这两年做项目的一个最大体会：连接这件事本身不难，难的是把连接放在整个系统的生命周期里去考虑——连接何时建立、何时复用、何时断开、连接不够时怎么办、连接变慢时如何兜底。如果你能把这些问题都想清楚，Java 连 MySQL 这一步就走得很扎实了，后面无论做微服务、数据同步还是大数据分析，底子都打得很牢。