Java连接MySQL从驱动选型到连接池实践：避坑指南

1. 写这篇的起因：一个连接异常折腾了我一晚上

如果你正在学Java，或者已经在做JavaWeb项目，大概率会踩到这一步：要用代码去读写MySQL里的数据，绕不开一个叫 mysql-connector-java 的驱动包。这个包本身不大，但就是因为它太常见，反而很少有人把它讲透。前几天一位读者给我发来一段报错，说用 Class.forName("com.mysql.jdbc.Driver") 加载驱动，结果一直抛 ClassNotFoundException，他查了半天，发现网上教程说的类名和自己项目里引的包对不上。这其实不是个例，而是我刚入行时也踩过的坑。

后来我帮他把依赖换成了 com.mysql:mysql-connector-j，把驱动类改成 com.mysql.cj.jdbc.Driver，问题立刻消失。这让我意识到：很多Java初学者甚至工作两三年的开发，对“Java连接MySQL”这件事的理解还停留在“照着网上的代码抄，能跑就行”的程度。一旦遇到版本变化、认证方式调整、时区报错，就会卡住。

所以这篇不是简单贴一段Hello World，而是把你从“会用DriverManager连一次”带到“能解释清楚连接原理、能处理常见报错、能写出工程级连接代码”的程度。内容包括驱动选型、最小连接程序、URL参数解读、踩坑复盘、连接池实践，全部来自我实际开发中验证过的方案。适合Java初学者、刚接触JDBC的学生，以及想系统梳理连接细节的开发者。

2. mysql-connector-java的选型：版本、坐标和加载方式

很多人忽略了一个关键事实：mysql-connector-java 这个老坐标已经不再更新了。Oracle官方从8.0.31之后，把驱动坐标改成了 com.mysql:mysql-connector-j。如果你还在用旧坐标，版本停在8.0.30或更早，虽然也能连MySQL，但新特性、安全修复都跟不上了。我第一次发现这个问题，是在一个老项目的pom.xml里看到 mysql:mysql-connector-java:5.1.47，当时觉得能用就行，结果换到MySQL 8.0后，连认证都过不去。

2.1 依赖坐标：Maven和Gradle怎么选

Maven项目直接在pom.xml里加这段：

xml复制<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <version>8.4.0</version>
</dependency>

Gradle项目用：

groovy复制implementation 'com.mysql:mysql-connector-j:8.4.0'

注意，8.4.0是当前比较稳的版本。别一看有9.x就无脑升，我记得9.0刚出来时有几个类路径变动，除非你有明确需求，否则生产环境用8.4.0这类长期支持版本更稳。驱动包不像业务代码，没必要追新。

2.2 连接器版本与MySQL版本怎么对应

这是连接失败最常见的隐形原因。我见过有人用5.1.x的驱动去连MySQL 8.0，结果报 Unable to load authentication plugin 'caching_sha2_password'。因为MySQL 5.7之前默认认证插件是 mysql_native_password，MySQL 8.0默认变成了 caching_sha2_password，老驱动不认识新插件，自然连不上。

大致对应关系如下：

这里有个容易混淆的点：旧驱动类 com.mysql.jdbc.Driver 在 mysql-connector-j 的8.x包里已经不存在了，取而代之的是 com.mysql.cj.jdbc.Driver。有些教程还在用老类名，照着写必然报ClassNotFoundException。如果你的项目里同时存在两个驱动jar，还会出现驱动重复注册的问题，后面我会专门说。

2.3 JDK版本对驱动的影响

JDK版本影响的是驱动包编译级别。mysql-connector-j 8.x通常要求JDK 8及以上。如果你还在用JDK 6/7，那只能退回5.1.x系列的驱动。现实中我遇到过一个极端情况：服务器上JDK是1.7，MySQL是5.6，项目用了8.0驱动，启动直接 UnsupportedClassVersionError。最后还是一致性对齐，把驱动降到5.1.49才解决。

所以选驱动版本前，先确认三件事：JDK大版本、MySQL大版本、驱动包版本。三者的兼容关系，比任何连接代码都重要。用一张图来记就是：JDK决定驱动能不能加载，MySQL决定驱动能不能认证，连接参数决定驱动能不能正常工作。

2.4 普通Web项目的jar引入方式

不用Maven/Gradle的读者，需要自己去官网下载jar包，然后放到项目的WEB-INF/lib目录下。下载时注意区分平台无关的jar包，别下成Windows安装版。下载后可以在IDE的Project Structure里把jar加到Libraries，或者在tomcat的lib目录下放一份。

我之前给一个学生排查问题，他下载的jar包只有几百KB，明显不对。其实完整的 mysql-connector-j-8.4.0.jar 有2MB左右。如果下载后大小不对，大概率是下载到了源码包或者被限速截断的文件，重新下载就行。手动管理jar包时，建议建一个lib目录统一存放，并且记录下来每个jar的版本号，方便以后排查。

3. 第一次连接：写一个最小可运行的JDBC程序

讲再多原理，不如跑通第一次。我建议你新建一个空项目，直接写一个main方法，把整个流程跑通。这样对DriverManager、Connection、Statement、ResultSet这几个核心对象会有直观认识。

3.1 准备数据库和测试表

先用MySQL客户端或Workbench执行下面的SQL：

sql复制CREATE DATABASE IF NOT EXISTS test_db DEFAULT CHARACTER SET utf8mb4;
USE test_db;

CREATE TABLE IF NOT EXISTS user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    age INT
);

INSERT INTO user (name, age) VALUES ('张三', 25), ('李四', 30);

注意建库时指定 utf8mb4 字符集，否则后面插入中文容易变成乱码。这一点很多教程不会强调，但实际开发中踩的人特别多。

3.2 最小连接代码逐行拆解

java复制import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class JdbcDemo {
    public static void main(String[] args) {
        String url = "jdbc:mysql://localhost:3306/test_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8";
        String username = "root";
        String password = "你的密码";

        try (Connection conn = DriverManager.getConnection(url, username, password);
             Statement stmt = conn.createStatement();
             ResultSet rs = stmt.executeQuery("SELECT id, name, age FROM user")) {

            while (rs.next()) {
                System.out.println("id=" + rs.getInt("id")
                        + ", name=" + rs.getString("name")
                        + ", age=" + rs.getInt("age"));
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

这段代码里，最核心的是 DriverManager.getConnection(url, username, password)。它内部会遍历已注册的驱动，找到能识别 jdbc:mysql:// 前缀的那个，然后建立物理连接。连接对象 Connection 是后续一切SQL操作的入口，Statement 用来执行SQL，ResultSet 用来装查询结果。

我用了 try-with-resources 写法，这样连接、语句、结果集都会自动关闭，省去手动 finally 里写一堆 close() 的麻烦。如果不想用这个语法，一定要在finally里逐个关闭，并且要判断 rs != null、stmt != null、conn != null，否则会出现连接泄漏。

3.3 结果验证和常见输出

跑起来后控制台会输出两行查询结果。如果报错，大概率是这几种情况：

• Access denied for user 'root'@'localhost'：用户名或密码错。
• Unknown database 'test_db'：数据库不存在。
• Communications link failure：MySQL没启动，或者端口不对，或者防火墙挡了。
• Public Key Retrieval is not allowed：URL参数里少了 allowPublicKeyRetrieval=true。

我建议你把这段代码当成“连接测试器”，以后在任何新环境部署，都先跑一次，能通再继续其他开发。这比把连接逻辑写在业务代码里排查要高效得多。

4. 连接URL里的门道：参数影响的不只是“能不能连上”

很多初学者以为URL只要写成 jdbc:mysql://localhost:3306/test_db 就够了，实际上驱动还提供了大量参数，这些参数直接影响连接的可靠性、安全性、性能。我在生产环境排查过不少问题，最终都定位到某个URL参数上。

4.1 jdbc:mysql://host:port/db 的基础结构

URL整体结构是：

code复制jdbc:mysql://[host][:port]/[database][?参数1=值1&参数2=值2]

• host：MySQL所在机器的IP或域名。本机可以用 localhost 或 127.0.0.1，但要特别注意，两者在Java里解析方式不同，localhost 可能走IPv6的 ::1，如果MySQL只监听IPv4，会连不上。遇到这种情况，改成 127.0.0.1 试试。
• port：默认3306，改了端口就要在URL里显式写。
• database：要连接的数据库名。
• ? 后面是参数，多个参数用 & 分隔。

4.2 useSSL与allowPublicKeyRetrieval

这两个参数可以说是MySQL 8出现后最常被讨论的组合。MySQL 8默认认证插件是 caching_sha2_password，如果连接不是SSL加密，第一次认证时需要从服务器获取RSA公钥来加密密码传输。这时候需要 allowPublicKeyRetrieval=true。

而 useSSL=false 表示不使用SSL加密通道。如果设置 useSSL=true，但服务端没配置SSL证书，会报错。所以本机和内网开发环境我一般直接用：

code复制?useSSL=false&allowPublicKeyRetrieval=true

生产环境如果要求加密传输，需要单独配置SSL证书，而不是简单改这两个参数。提醒一点：allowPublicKeyRetrieval=true 在公网环境有中间人攻击风险，尽量只在可信网络使用。

4.3 serverTimezone与连接时区陷阱

驱动在连接MySQL 8时会尝试获取服务器时区，如果两边时区不一致，它会报：

code复制The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized...

这个报错看起来像乱码，其实是MySQL返回的时区名和驱动里的时区库对不上。解决方案就是URL里显式指定时区：

code复制serverTimezone=Asia/Shanghai

更推荐做法是让Java和MySQL都使用UTC存储时间，由应用层做时区转换。不过对大多数国内项目，直接指定 Asia/Shanghai 最简单。这里有个细节：连接时区影响的是 java.sql.Timestamp 和 DATETIME 的转换，如果你发现查出来的时间比数据库少了8小时或多了8小时，八成就是时区参数没设置对。

4.4 其他值得设置的参数

除了上面几个，还有几个参数我建议你一开始就养成习惯加上：

其中 rewriteBatchedStatements=true 是很多团队忽略的性能优化点。不加这个参数时，addBatch() 提交的SQL还是一行一行发给MySQL；加了之后，驱动会把多条INSERT合并成一条 INSERT INTO ... VALUES (..),(..),(..)，性能能提升好几倍。

5. 我踩过的坑：从ClassNotFoundException到连接泄漏

连接MySQL的成功率，不是由代码写法单一决定的。驱动、认证、网络、参数、资源释放，任何一环出问题都会让你怀疑人生。我把这几年遇到的高频问题做一次复盘，希望你能少走弯路。

5.1 Class.forName是否还需要

网上很多老教程都有这一行：

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

实际上，从JDBC 4.0开始，驱动包里的META-INF/services/java.sql.Driver文件会自动注册驱动，DriverManager 会自动发现它。所以现代项目里这行可以省略。但为什么还要提？因为有些老版本驱动或者特殊类加载环境下，自动注册不生效，手动 Class.forName 是一种兜底方案。

我的建议是：新代码不要写，但看到别人的代码里有，也不要觉得奇怪。如果遇到 No suitable driver found，可以考虑加回这一行，然后排查classpath里到底有没有驱动包。

5.2 通信链路异常与防火墙

Communications link failure 是第二高频的报错。它包含的异常信息可能让人误以为是数据库问题，比如：

code复制Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago.

排查顺序如下：

1. 在命令行执行 telnet 127.0.0.1 3306，看端口是否开放。
2. 确认MySQL服务是否启动：Linux执行 systemctl status mysqld，Windows看服务列表。
3. 确认MySQL的bind-address是否允许远程访问。如果 my.cnf 里是 bind-address=127.0.0.1，那么远程机器肯定连不上，需要改成 0.0.0.0。
4. 检查防火墙和云安全组。有一回线上连不上，最后发现是云服务器安全组没放行3306端口，本地telnet一直是超时。

还有一个容易被忽略的点：MySQL的 max_connections 满了之后，新连接也会报类似错误。所以如果你用的是共享数据库，先看连接数，而不是反复重启服务。

5.3 驱动重复注册与类加载顺序

如果classpath里同时存在旧版 mysql-connector-java 和新版 mysql-connector-j，可能出现两个不同包名的Driver都被DriverManager扫描到。虽然两者都注册了，但可能因为类名冲突导致加载到错误的版本，行为变得不可预测。

比如旧驱动用 com.mysql.jdbc.Driver，新驱动用 com.mysql.cj.jdbc.Driver，但新驱动包里也保留了一个 com.mysql.jdbc.Driver 用于向后兼容。这个兼容类内部实际委托给 com.mysql.cj.jdbc.Driver，如果加载顺序不对，可能新旧逻辑混在一起。解决方式很粗暴：去掉旧包，只保留一个新坐标的包。

5.4 连接用完不关导致的坑

我见过最典型的故障：一个定时任务每5分钟执行一次，每次都 DriverManager.getConnection，但 Connection 没关闭。系统运行几天后，MySQL连接数被打满，其他服务全部报 Too many connections。最后DBA手动kill进程才恢复。

所以连接资源必须要关。如果你不想每次手写那么长的finally，至少做到两点：

• 使用 try-with-resources 语法。
• 在整个应用生命周期内，不要频繁创建/销毁连接，交给连接池管理。

5.5 中文乱码问题

中文乱码的根源是三层字符集不一致：Java文件编译字符集、连接参数字符集、数据库表字符集。常见表现是查询返回的name显示 ???，或者插入后数据库里看到乱码。

解决办法分三步：

1. 数据库建库建表用 utf8mb4。
2. URL加 characterEncoding=utf8。
3. Java文件本身保存为UTF-8编码。

这三步都做对，基本不会乱码。如果还乱，检查MySQL的 character_set_server 系统变量，必要时在my.cnf里设置：

ini复制[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

6. 从Demo到工程：连接池和配置管理

如果你只是做练习，DriverManager.getConnection 完全够用。但一旦进入Web项目、微服务、定时任务这类场景，裸连带来的性能和稳定性问题会立刻暴露出来。这里说一下我实际用的工程化方案。

6.1 为什么不能用DriverManager裸连

裸连每次都要走一次完整的TCP握手、MySQL认证、权限校验，在高并发下连接建立开销非常可观。而且连接对象的创建不是线程安全的，你在多线程环境里共享一个Connection，会出现数据错乱；不共享，每个线程都建连接，数据库很快会被打爆。

连接池的核心思路就八个字：复用连接，按需创建。提前准备好一批连接放到池子里，调用方只是“借用”，用完归还。这不仅避免反复握手，还能通过参数控制最大连接数，防止数据库被压垮。

6.2 HikariCP最小配置

目前Spring Boot默认内置的就是HikariCP，性能好、配置简单。如果是原生Java项目，引入两个依赖：

xml复制<dependency>
    <groupId>com.zaxxer</groupId>
    <artifactId>HikariCP</artifactId>
    <version>5.1.0</version>
</dependency>

获取连接和普通JDBC几乎一样：

java复制HikariConfig config = new HikariConfig();
config.setJdbcUrl("jdbc:mysql://localhost:3306/test_db?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8");
config.setUsername("root");
config.setPassword("你的密码");
config.setMaximumPoolSize(20);
config.setMinimumIdle(5);
config.setConnectionTimeout(3000);

HikariDataSource dataSource = new HikariDataSource(config);

try (Connection conn = dataSource.getConnection();
     Statement stmt = conn.createStatement();
     ResultSet rs = stmt.executeQuery("SELECT 1")) {
    // 业务代码
}

maximumPoolSize 建议根据数据库 max_connections 和应用并发数一起算。比如数据库最大连接数是200，有4个应用实例，平均分配，每个实例最大连接池可以设为40，再留一点余量给运维和后台任务。公式是：单实例最大连接数 =（数据库max_connections - 备用连接数）/ 应用实例数。

6.3 配置外置与多环境

连接参数硬编码在代码里是绝对要避免的。尤其是密码，一旦代码库泄漏，数据库就等于裸奔。我一般用环境变量或配置文件拆分：

code复制jdbc.url=jdbc:mysql://${MYSQL_HOST}:${MYSQL_PORT}/test_db?useSSL=false&serverTimezone=Asia/Shanghai
jdbc.username=${MYSQL_USER}
jdbc.password=${MYSQL_PASSWORD}

这样不同环境（dev/test/prod）只需要设置不同的环境变量，代码和配置基本不用改。Spring Boot里可以配合 application.yml 的 @Value 注入，或者用 @ConfigurationProperties 读取整个数据源配置。
这里特别提醒：不要把生产库密码提交到Git仓库。我已经不是第一次听说有人把带数据库密码的配置文件推到公开仓库，然后被爬虫扫到，数据库被删库勒索了。配置外置不是可选项，而是安全底线。

6.4 连接池监控

连接池不是配完就不管了。HikariCP提供了 Metrics 接口，可以接入Prometheus或Micrometer。关键监控指标有三个：

• active：正在使用的连接数。
• idle：空闲连接数。
• pending：等待获取连接的线程数。

如果 active 长期接近 maximumPoolSize，说明连接不够用，要调大最大连接数或排查慢SQL。如果 pending 经常大于0，说明应用在等连接，很可能有连接泄漏或者某个连接持有时间过长。有一次我通过监控发现一个定时任务持有连接长达3分钟，就是因为事务里调用了外部HTTP接口，这种场景一定要把耗时操作移出事务。

另外要关注 connectionTimeout。默认30秒对我来说太长了，建议改短到3~5秒，这样数据库一旦异常，应用能快速失败并触发熔断，而不是所有线程都卡在等连接上。

7. 经验收尾：从“连上”到“会调优”的分水岭

写到这里，你已经不再是一个只会复制粘贴连接代码的人。你能解释 mysql-connector-j 和 mysql-connector-java 的区别，知道 caching_sha2_password 为什么导致需要 allowPublicKeyRetrieval，明白连接池为什么是Web应用的标配。这些知识看起来零散，但它们组合在一起，就是你排查线上数据库连接问题的底气。

我个人在实际项目里的习惯是：任何新环境，先写一个两行代码的连通性测试，确认驱动、URL、账号、数据库四要素全对，再往上叠框架。版本不随意动，升级驱动前先查兼容性矩阵。连接参数统一维护在配置中心，不散落在各个微服务里。

最后分享一个排查小技巧：遇到连接问题，第一时间打开MySQL的 SHOW PROCESSLIST; 和 SHOW STATUS LIKE 'Threads_connected';，看看当前连接数和正在执行的SQL。很多情况下，问题不在Java代码，而在数据库这边。把连接数曲线和应用日志时间线对齐，往往一眼就能看出是谁在占用连接。多练几次，你就能从“看见报错就慌”变成“按顺序排查，稳如老狗”。