MySQL驱动全链路实战：版本选型、连接配置、报错排查与参数调优-代码聚汇网

MySQL驱动全链路实战：版本选型、连接配置、报错排查与参数调优

本多敏行·2026-09-04·阅读 70 GEO检测（免费）

MySQL驱动JDBC连接池

|难度：普通|阅读约 40 分钟

我刚开始用 Java 连 MySQL 那会儿，第一行代码就是 Class.forName("com.mysql.jdbc.Driver")。当时完全不知道这行到底在干嘛，只知道不写就报 ClassNotFoundException，写了又偶尔冒出 Public Key Retrieval is not allowed。后来被“驱动”这东西折磨了一整个项目周期，才慢慢摸清楚它到底替应用和数据库之间干了多少活。

很多人以为 MySQL 驱动就是“下载一个 jar 包，放进依赖里，能连上就完事”。真到了生产环境，你会发现连接超时、版本不兼容、批量插入慢得离谱、换个服务器就连不上……这些问题最终全都能追溯到驱动这一层。这篇就围绕 MySQL 驱动，把从驱动选型、连接配置到高频报错排查、参数调优、安全升级的完整链路讲清楚，适合刚接触数据库连接的开发新手，也适合那些“能用但总出幺蛾子”的项目维护者。

1. 驱动是什么：它替应用和 MySQL 之间干了哪些“翻译”活

1.1 驱动不是“连接工具”，而是协议翻译器

第一次接触 MySQL 驱动时，我下意识把它理解成一根“数据管道”：应用这头怼进去 SQL，数据库那头返回结果。这个理解不算错，但太粗糙了。

MySQL 服务端和 Java 应用跑在两个完全不同的进程里，甚至可能不在同一台机器上。它们之间要通信，得遵循一套双方都认的协议——MySQL 客户端/服务端协议。这套协议规定了握手怎么发起、认证怎么完成、SQL 文本怎么封装、结果集怎么分包、错误码怎么定义。而驱动，就是把这套二进制协议翻译成 Java 对象的那层代码。

举个例子：你在 Java 里写 stmt.executeQuery("SELECT id, name FROM user WHERE id = 1")，驱动要做的事远不止“把字符串发给 MySQL”。它要先建立 TCP 连接，完成 MySQL 的握手认证（可能涉及密码哈希算法），然后把 SQL 语句按协议格式编码成 packet 发出去，再接收服务端返回的二进制结果流，一行一行地解析成 ResultSet。如果 SQL 里有 ? 占位符，驱动还需要把参数按类型编码后拼进协议包。

这也是为什么“驱动”和“客户端工具”不是一回事。Navicat、DataGrip、命令行 mysql 客户端，它们各自内置了自己的驱动实现。你在这些工具里能连上 MySQL，不代表你的 Java 项目也能连上——后者的驱动得单独引入。

1.2 JDBC 驱动四类说，实际只需关心 Type 4

Java 的 JDBC 规范把驱动分成四种类型：

Type 1：JDBC-ODBC 桥，通过本机 ODBC 驱动再转一层，早年被用于快速尝鲜，性能和兼容性都是灾难，现在已经很少有人用了。
Type 2：部分 Java 实现，部分本地代码实现，依赖客户端本机安装的 MySQL 客户端库。
Type 3：纯 Java，但走中间件服务器转发，多见于特殊网络隔离场景。
Type 4：纯 Java 实现，直接通过网络协议连接数据库，不依赖任何本机库。

现在的 MySQL Connector/J 就是 Type 4 驱动。你不需要在服务器上安装 MySQL 客户端，不需要配 ODBC 数据源，只要 JVM 能访问到 MySQL 的 IP 和端口，驱动就能直接完成协议交互。这种设计让 Java 应用部署变得非常简单——换个服务器，只要 JDK 版本和网络通就行。

Type 4 驱动的缺点不是没有，比如它无法利用一些本机客户端特有的优化，但对于绝大多数应用场景，Type 4 是唯一需要关心的类型。那些“请先安装 Access 64 位系统驱动程序”“ODBC 驱动程序管理器未发现数据源”之类的报错，多半是桌面端工具或非 Java 项目的问题，后面我会在排查章节单独讲。

1.3 从一次 Class.forName 报错说起：驱动类为什么找不到

很多老教程会写这一行：

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

这段代码的意思是：让 JVM 加载 com.mysql.jdbc.Driver 这个类。这个类的静态初始化块里会做一件事——向 DriverManager 注册自己。

但注意，从 JDBC 4.0 开始，只要你在 classpath 里引入了驱动 jar 包，DriverManager 会自动通过 ServiceLoader 机制加载驱动，Class.forName 这行其实可以不写。所以你会看到：新项目里有人不写这行也能连，有人写了反而因为类名写错报 ClassNotFoundException。

类名写错这事特别常见。MySQL Connector/J 5.x 时代，驱动类是 com.mysql.jdbc.Driver。到了 8.x 时代，驱动类改成了 com.mysql.cj.jdbc.Driver。如果你的 jar 是 8.x 但代码还写老类名，启动时就会报找不到类。更诡异的是，某些中间件会尝试按老类名加载，一旦失败就静默跳过，然后抛出一句含糊的 No suitable driver found。

所以排查驱动加载问题时，第一件事永远是确认三件事：你用的驱动版本是什么；你的连接 URL 里的地址格式对不对；你的依赖管理工具到底把哪个 jar 打进去了。这三件事互相影响，任何一环错了，报错都长得差不多。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. Connector/J 版本变迁：驱动名和连接串参数都在进化

2.1 com.mysql.jdbc.Driver 到 com.mysql.cj.jdbc.Driver

MySQL 官方 Java 驱动叫 Connector/J。我从 5.1.x 用到 8.x，感受最深的是：这玩意儿表面上只是驱动，实际上每次大版本升级都会夹带一批“破坏性变更”。

5.x 时代最常用的是 5.1.47、5.1.49。这个版本系列的驱动类名是 com.mysql.jdbc.Driver，连接 URL 通常长这样：

code复制jdbc:mysql://localhost:3306/testdb

8.x 时代（目前主流是 8.0.x，官方现在已经推 9.x），驱动类名变成了 com.mysql.cj.jdbc.Driver，连接 URL 推荐写成：

code复制jdbc:mysql://localhost:3306/testdb?useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

如果项目用的是 Spring Boot 2.x + MySQL 8，通常由 Maven 依赖 mysql:mysql-connector-java 拉取驱动。Spring Boot 2.7 之后，GAV 坐标从 mysql:mysql-connector-java 改成了 com.mysql:mysql-connector-j，这一点很多人没注意，导致升级依赖时明明写了却拉不下来。

驱动类名的变化其实反映了内部包结构的重构。8.x 把核心代码迁移到了 com.mysql.cj 包下，老包名只是保留了一段兼容层。到了 8.0.31 之后的某些版本，连“com.mysql.jdbc.Driver”这种兼容入口都表现出一些异常行为，最稳妥的办法是代码里不写驱动类名，连接串交给连接池和 DriverManager 自动识别。

2.2 连接串常见参数逐个拆解

连接串的参数配置，是驱动最容易出问题的地方。我根据自己的踩坑经历，把最常见的几个参数列出来：

参数	常用值	作用与踩坑故事
`useSSL`	`false` / `true`	本地开发和内网环境建议 `false`，否则 MySQL 8 默认开启 SSL，证书配置不当会握手失败。公网环境建议 `true` 并配证书
`serverTimezone`	`Asia/Shanghai`	不配会报 `CST` 时区识别异常，因为 MySQL 8 的 `CST` 可能被理解成美国中部时间
`allowPublicKeyRetrieval`	`true`	MySQL 8 默认使用 caching_sha2_password 认证，如果连接没有提前建好 SSL 通道，会需要服务端公钥；不设 `true` 会报 `Public Key Retrieval is not allowed`
`characterEncoding`	`utf8mb4`	不配可能导致中文乱码；MySQL 8 默认字符集已经是 utf8mb4，但连接层仍建议显式声明
`connectTimeout`	`3000`	TCP 连接超时，单位毫秒。不配时可能因网络问题卡很久
`socketTimeout`	`60000`	SQL 执行超时；不配的话，一条语句卡死会一直占着连接不释放
`rewriteBatchedStatements`	`true`	批量插入优化关键参数，默认 `false`，后面调优章节细说

这些参数用得好不好，直接决定连接稳定性和性能。网上很多“复制即用”的连接串喜欢把所有参数堆一起，我不建议这么干。参数越多的连接串越难排查问题，建议用最少参数让连接跑通，再逐步加。

2.3 下载与引入驱动的正确姿势

关于“mysql jdbc 驱动下载”，最权威的来源是 MySQL 官网的 Connector/J 下载页，千万别从第三方博客的网盘链接下 jar 包。倒不是说你一定会中招，而是第三方打包的 jar 经常版本号和实际内容对不上，出问题后你连排查的基础都没有。

Maven 项目用依赖坐标引入：

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

Gradle 项目：

gradle复制implementation 'com.mysql:mysql-connector-j:8.0.33'

没有构建工具的老项目，直接下载 jar 放到 WEB-INF/lib 或 lib 目录下也行。但有个坑：如果项目里同时存在多个版本的 MySQL 驱动 jar，比如 Tomcat 的 lib 目录下有个老版本，应用本身的 lib 里又带了个新版本，类加载器会因为加载顺序不同导致某些方法找不到或行为异常。我之前排查过一个问题：本地 IDE 跑得好好的，部署到服务器就报 Unable to load authentication plugin 'caching_sha2_password'，后来发现是 Tomcat 全局 lib 里的 5.1.x 驱动被优先加载了。所以务必检查部署环境的全局类路径。

3. 配套环境配置里的隐形门槛：MySQL 安装与客户端连接

3.1 mysql 安装完成后，为什么 JDBC 仍连不上

很多人会从“mysql 安装教程”“mysql 安装配置教程”开始，把 MySQL 8.0 服务端装好后，用命令行 mysql -u root -p 能登进去，但一换成 Java 程序就连不上。这时候问题通常不在驱动，而在 MySQL 服务端的访问控制。

MySQL 的用户认证信息分两部分看：用户名和允许登录的主机。命令行在本地登录时，连接来源是 localhost；Java 程序如果跑在同一台机器上，一般也用 localhost；但如果你用 Docker 起 MySQL，Java 在宿主机上跑，那 Java 程序访问的 host 是 127.0.0.1，而 MySQL 里面 root 用户可能只允许 localhost 登录。此时会看到：

code复制Access denied for user 'root'@'localhost'

注意这个报错里的 @'localhost' 是 MySQL 视角看到的来源地址，不是你的直觉判断。排查方式是执行：

sql复制SELECT user, host, plugin FROM mysql.user;

看 root 用户对应的 host 是什么。Docker 部署常见坑是 root 的 host 为 %，但密码认证插件是 caching_sha2_password，而驱动版本太老不支持。这又会绕回驱动版本的兼容性问题。所以“装好了却连不上”，排查顺序应是：网络通不通 → MySQL 有没有监听端口 → 用户允不允许来源主机 → 密码插件驱动认不认识 → 是不是 SSL/公钥问题。

3.2 环境变量和 PATH 的坑

搜“mysql 配置环境变量”的开发者，大多是想在命令行里直接敲 mysql 命令。这里要分清楚：配置 MySQL 客户端命令的环境变量跟 Java 驱动一毛钱关系都没有，但很多人被网上教程搞混。

比如你在 Windows 上把 MySQL 的 bin 目录加进 PATH，只是为了能用 mysql 命令。而 Java 程序连 MySQL，用的是 TCP 协议访问 3306 端口，完全不依赖 PATH。反过来，如果你把 ODBC 驱动、JDBC 驱动装在系统里，但没把对应的类路径加对，那命令行能连不代表应用能连。

比较隐蔽的坑是：机器上装了 MySQL 5.7 的命令行客户端，又装了 MySQL 8.0 的服务端，命令行里敲 mysql --version 显示 5.7，但服务端实际是 8.0。如果你在脚本里用了 5.7 客户端不认识的认证方式，可能连接时出问题。这跟驱动程序同理——客户端工具和服务端版本不一致，会把问题伪装成“连接失败”。

3.3 Navicat / DataGrip / 命令行三方并存的驱动加载差异

Navicat 连 MySQL 8 如果提示 Client does not support authentication protocol requested by server，一般可以在用户管理里把认证插件改成 mysql_native_password，或者升级 Navicat 版本。DataGrip 则内置了较新的驱动，通常能直连 MySQL 8，出问题多半是 SSH 隧道或 SSL 配置。

这里我自己的建议是：不要在好几个客户端工具里反复换着试，而是先用命令行验证 MySQL 本身是健康的，然后用一个客户端工具（推荐 DataGrip 或新版 Navicat）验证 TCP 连接，最后才回到自己的代码里测试 JDBC。这样能把“服务端问题”和“驱动问题”切分开。命令行不是驱动，但它是排查驱动问题最有效的参照物。

4. 高频报错排查链路：从连接超时到驱动不兼容

4.1 Error 2002 (HY000)：Socket 连不上时的排查顺序

搜这条错误的人通常是在 Linux 或 macOS 下启动服务时看到的：

code复制ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

注意，这条报错出现时，客户端找的是 socket 文件，不是 TCP 端口。这意味着客户端认为你打算走“本地 socket”方式连接，而不是 TCP。命令行里直接敲 mysql 不带 -h，默认就会去找 socket 文件；如果 MySQL 没有启动，或者 socket 文件路径不对，就会报这个错。

Java JDBC 驱动不会用 Unix socket（除非用了特殊包装），所以 Java 程序报 2002 错误通常是另一种形态：Communications link failure，后面跟着连接超时。排查顺序如下：

先确认 MySQL 进程是否存活：systemctl status mysqld 或 ps aux | grep mysqld。
再确认端口监听：netstat -tlnp | grep 3306，如果监听在 127.0.0.1 而你的应用从别的机器连，这就会失败。需要把 bind-address 改成 0.0.0.0 或具体网卡地址。
检查防火墙和云安全组，这个不用赘述。
看驱动报错的时间点——如果瞬间失败，大概率是端口不可达或服务没起来；如果卡了很久才失败，大概率是防火墙丢弃包导致的超时，此时应缩短 connectTimeout 让报错更快暴露。

我在本地开发时最常踩的是第 2 步。Docker 里把 MySQL 的 3306 端口映射到了宿主机的 3306，但容器内部的 MySQL 配置里 bind-address 还是 127.0.0.1，导致宿主机访问不到。修改 my.cnf 后重启容器才能解决。

4.2 ODBC 驱动管理器 [IM002]：数据源名称未找到

code复制[IM002] [Microsoft][ODBC 驱动程序管理器] 未发现数据源名称并且未指定默认驱动

这条报错出现的场景一般是 Windows 桌面程序或者 Excel/Power BI 通过 ODBC 连 MySQL。看到“未发现数据源名称”，很多人以为是 MySQL 的库名写错了，其实是 ODBC 层压根没找到对应的 MySQL ODBC 驱动。

ODBC 连接串通常长这样：

code复制Driver={MySQL ODBC 8.0 Unicode Driver};Server=localhost;Database=testdb;User=root;Password=123456;Option=3;

Driver 那段必须和你系统里安装的驱动名称完全一致。在“ODBC 数据源管理器”里可以看到已安装驱动列表，32 位和 64 位的驱动管理器是分开的。你的 Excel 是 32 位就得用 32 位的 ODBC 驱动管理器去配置数据源，反过来也是一样。这类问题跟 Java 驱动没关系，是典型的“驱动名称/位数不匹配”。

我自己的建议是：Windows 上跨工具使用数据库时，优先用最新的 MySQL ODBC 8.x 驱动，装的时候可以勾选 32 位和 64 位都装。但同一个驱动管理器里，驱动名称不要出现两个版本混着配置的情况，不然你下次看连接串会疯掉。

4.3 64 位 Access/ODBC 驱动冲突与“位数不匹配”

如果你看到的是“请先安装 access 数据库 64 位系统驱动程序”或“64 位引擎不支持 dbc 数据，只支持 access 数据”，这通常是从 Excel/Access 导入导出数据时，Office 的位数和 ACE 驱动位数不一致导致的。

这类报错的本质是：Microsoft Access Database Engine（ACE）有 32 位和 64 位两个版本，Office 安装的是 64 位，那 ACE 驱动也必须用 64 位；反之亦然。不能混装。在连接串里指定 Microsoft.ACE.OLEDB.12.0 或 Microsoft.ACE.OLEDB.16.0 时，也分位数。

MySQL 项目里会遇到这个，多半是业务方需要把 MySQL 数据导入 Access，或者用 Excel 连接 MySQL 做报表。我的处理方法是：别走 Access 引擎，直接用 MySQL ODBC 数据源 + Excel 的“获取数据”功能。这样可以绕开 ACE 驱动的位数诅咒。如果实在绕不开，卸载掉当前 Office 的位数版本，统一换到同一个位数，再装对应位数的 ACE 驱动。

4.4 驱动数字签名与“被检测为易受攻击”的处理原则

Windows 下装驱动时偶尔会碰到“Windows 无法验证此设备的驱动程序的数字签名”，或者“某个安全设置将其检测为易受攻击的驱动程序”。这个提示要分成两种场景看。

第一种场景是 Windows 系统级驱动，比如网卡、显卡、主板驱动。这类驱动如果没有通过微软的签名验证，系统会阻止安装。处理办法是去硬件厂商官网下载签名版本，而不是在系统设置里关闭驱动签名强制。关闭签名强制虽然能用，但会降低系统安全性，尤其是现在 Windows 对驱动的要求越来越严。

第二种场景和安全软件有关。安全软件扫描到某个驱动组件存在已知 CVE 漏洞，会提示“易受攻击的驱动程序”。我看到这个提示时的第一反应不是去关安全软件，而是去查驱动版本是否太老，有没有修复版本。MySQL 的 JDBC 驱动如果版本很老，也存在已知漏洞，比如 8.0.19 之前的一些版本在特定配置下存在风险。更新到最新稳定版是标准解法。

记住一个原则：驱动签名、安全提示、漏洞警告，都是“驱动生命周期管理”的一部分。别因为“能跑就不动”而在生产环境留下一个明知有漏洞的老驱动。

5. 驱动参数调优与数据库压力的关系：拿实际场景说事

5.1 一个“mysql中int+5”串台的问题：驱动真的会改 SQL 吗

热搜里有一句“mysql中int+5”，这个说法不是 SQL 标准里的东西，更像是某些数据库产品里对 int 类型的扩展处理。放到驱动语境下，我会理解为：很多开发者在写 SQL 时对类型处理不严谨，导致驱动层产生了“意外改 SQL”的假象。

举一个实际例子。有朋友跟我说驱动把他 SQL 里的参数改掉了。他的代码是：

java复制ps.setObject(1, userInput);

如果 userInput 是字符串 "1 OR 1=1"，驱动会严格按字符串类型绑定，不会帮你拼进 SQL。但如果拼接 SQL 的姿势不对：

java复制stmt.executeQuery("SELECT * FROM user WHERE id = " + id);

那驱动接到的是一个已经拼接好的完整 SQL，里面的 id 早就变成了 SQL 片段的一部分。这个锅不能让驱动背。

再比如 MySQL 的 int 类型在驱动里对应 java.lang.Integer，但与 INT UNSIGNED 对应的是 java.lang.Long。如果你用 getInt() 去取一个 UNSIGNED INT 字段，超过 2^31 的值会溢出。这看起来像驱动“改了数据”，其实是 API 使用不当。处理办法是用 getLong() 或直接映射成 Long 类型。所以建议大家把“mysql中int+5”这类困惑理解为类型边界问题，逐个明确表字段类型和 Java 类型的映射，而不是去猜驱动改写了 SQL。

5.2 批量插入太慢？先看 rewriteBatchedStatements

这是驱动参数里最实用的一条。Java 里用 PreparedStatement 做批量插入时：

java复制connection.setAutoCommit(false);
PreparedStatement ps = connection.prepareStatement("INSERT INTO t (name, age) VALUES (?, ?)");
for (int i = 0; i < 10000; i++) {
    ps.setString(1, "name" + i);
    ps.setInt(2, i);
    ps.addBatch();
    if (i % 1000 == 0) {
        ps.executeBatch();
    }
}
connection.commit();

默认情况下，驱动把每条 insert 单独发给 MySQL，仍然是一条条的插入，和循环执行单条 insert 没有本质区别。只有当连接参数里加了 rewriteBatchedStatements=true，驱动才会把多条 insert 重写为一条多值 insert：

code复制INSERT INTO t (name, age) VALUES ('name1', 1), ('name2', 2), ...

这个优化效果非常明显。我测过一次插入 10 万行数据，不开启时耗时接近 40 秒，开启后降到 3 秒以内。网络往返次数大幅减少，效果立竿见影。

但 rewriteBatchedStatements=true 不是什么时候都该开。如果批量语句包含 INSERT ... ON DUPLICATE KEY UPDATE 这类带复杂子句的 SQL，驱动重写时可能出现怪异行为。我自己遇到过的问题是批量插入里带 LAST_INSERT_ID() 依赖时，重写后返回值语义会变化，导致获取自增主键出错。所以建议是：普通批量 insert 场景务必开启；有复杂 SQL、事务边界要求严格时，先在测试库验证。

5.3 连接池配置与超时重置：HikariCP 和 Druid 参数推荐

驱动本身管理单个连接，而连接池负责管理一群连接。你配置的驱动参数会被连接池创建连接时继承，所以在连接池里设置连接串和驱动参数是常态。下面给一套我实际在用的配置，基于 HikariCP：

yaml复制spring:
  datasource:
    hikari:
      minimum-idle: 5
      maximum-pool-size: 20
      connection-timeout: 3000
      idle-timeout: 600000
      max-lifetime: 1800000

有几个重点：max-lifetime 要小于 MySQL 的 wait_timeout。如果 MySQL 服务端的空闲连接超时是 8 小时，那连接池里的连接最多存活 30 分钟就重建，就能避开“连接池拿到的连接其实已被 MySQL 断开”的问题。connection-timeout 建议别设太长，否则数据库出问题时应用层请求会大量堆积，把线程池也拖垮。

如果是 Druid，推荐打开这些参数：

yaml复制spring:
  datasource:
    druid:
      test-while-idle: true
      validation-query: SELECT 1
      keep-alive: true
      keep-alive-between-time-millis: 30000

SELECT 1 这种探测语句会额外消耗一次数据库往返，所以在高并发场景下不要频繁执行。HikariCP 默认不做 test-while-idle，而是依赖 max-lifetime 主动淘汰连接，这也是一种设计取舍。

6. 驱动安全加固与升级：被扫描软件提醒的坑

6.1 老版本 JDBC 驱动的漏洞和升级路线

很多开发者的依赖管理里，MySQL 驱动版本常年不升。我见过不少项目还在用 5.1.47，理由是“一直跑得好好的，不敢动”。但这里有一个隐患：老版本驱动不支持 MySQL 8 的 caching_sha2_password 认证，未来如果要升级 MySQL 服务端，应用会大面积连不上。

驱动本身也是攻击面。旧版 Connector/J 存在已知漏洞，安全扫描工具报出“易受攻击的驱动程序”时，基本指向这类问题。升级驱动的收益除了安全修复，还有兼容性和性能提升。比如 8.0.26 之后的版本修复了一些 SSL 相关的握手问题，8.0.31 优化了大结果集解析的内存占用。

升级路线我建议这样走：代码层面先把 Class.forName 去掉，连接串参数做最小化整理；然后把驱动版本从 5.1.x 升到 8.0.x，注意驱动类名；最后跑一遍全量核心用例，重点看日期时间处理、大字段读写、批量插入和特殊字符场景。

6.2 驱动版本升级后的兼容性核对

升级到 8.x 后，有一个常见的隐性坑：默认时区处理。5.1.x 时代不配 serverTimezone 也能连，因为驱动会使用 JVM 默认时区。8.x 对时区更敏感，启动时如果没有正确识别服务端时区，会直接抛异常或返回偏移时间。处理方法是连接串里显式加 serverTimezone=Asia/Shanghai，不要把时区判断留给驱动自动探测。

还有字符集问题。8.x 默认连接字符集与 5.x 不同，如果你的表里存了 emoji 或生僻字，记得表和连接都使用 utf8mb4。驱动层面要加 characterEncoding=utf8mb4，并确认 MySQL 服务端的 character_set_server 也是 utf8mb4。

如果项目里同时访问多个 MySQL 实例，版本还不同，我强烈建议按实例区分数据源，不要共用一个连接串和驱动配置。因为连接串里的参数是全局生效的，一个参数对 5.7 友好，对 8.0 可能就是性能杀手。比如 5.7 上常用的某些 SQL mode 相关配置，在 8.0 里可能触发兼容告警。

6.3 一份可以照着抄的驱动上线检查清单

这里分享我每次排查或升级 MySQL 驱动时都会走的检查流程，基本能覆盖九成的问题：

驱动 jar 是不是只有一份？在 classpath 里全局搜一下 mysql-connector，排除多版本并存。
连接串参数是否最少化？先不加任何参数连一次，报什么错再针对性加。
服务端版本和驱动版本是否兼容？MySQL 8 尽量配 Connector/J 8.0.2x 以上。
认证插件是什么？SHOW VARIABLES LIKE 'default_authentication_plugin'; 如果是 caching_sha2_password，连接串要配合 allowPublicKeyRetrieval=true（非 SSL 场景）。
时区、字符集是否显式声明了？不要在线上靠默认值赌运气。
批量插入是否开了 rewriteBatchedStatements？没开但数据量大，先开再测。
连接池 max-lifetime 是否小于 MySQL wait_timeout？大于等于的话，高峰期会出现偶发连接重置。
有没有安全扫描报告提示驱动版本风险？有就准备升级窗口。
升级后有没有跑过“日期写入再读回”“中文/emoji 写入”“批量插入”“大字段读写”这四类回归用例？

写到这儿，我想起一个很小的细节，但特别值得提。有一次我把生产环境的 MySQL 从 5.7 升到 8.0，因为只改了服务端没升级驱动，导致凌晨定时任务大面积报错。报错信息不直接说“版本太老”，而是绕来绕去的 Authentication plugin 'caching_sha2_password' cannot be loaded。当时我盯着连接池配置看了半小时，最后才发现是应用 lib 里的驱动还停在 5.1.46。所以后来我在所有项目里都形成了一条规矩：每次动 MySQL 服务端版本前，先把驱动版本提到对应大版本的最新稳定版，再谈其他优化。驱动这个东西，平时感觉不到它的存在，等它出问题的时候，往往就是整个应用最脆弱的时候。提前把这些配置和版本关系理清楚，能给你省下很多半夜起来排查的时间。