MySQL选择驱动不踩坑:Connector/J 9.6适配指南
2024 年初,我曾介绍过这个话题。如何选择适合的 MySQL Connector/J 版本
时隔两年,我们再聊聊在JDBC驱动选择方面的内容,我们需要关注什么。比如,字符集爆炸、TLS握手失败的原因,Java开发者该如何避开Connector/J的深坑。
01. 版本演进:从 5.1 到 8.4 的跨越
MySQL Connector/J 的版本路线就像一场技术迭代的马拉松。目前企业级环境主要存在三条战线:
- 5.1.x 遗留线:已停止维护,仅支持
mysql_native_password,对 MySQL 8.0+ 的新特性几乎零支持 - 8.0.x 主力线:当前生产环境的主流,完整支持
caching_sha2_password和 TLS 1.2/1.3 - 8.0.22: 支持 TLS v1.3
- 8.0.42: 支持 OpenSSL 3.0.16
- 8.x/9.x 前瞻线:配合 MySQL 8.4 LTS 、MySQL 9.x 发布,优化了 JSON Duality Views 支持和 X DevAPI 性能
一张表格告诉你怎么选。
| 维度 | Connector/J 5.1 | Connector/J 8.0.33+ | Connector/J 8.4.0/9.x |
|---|---|---|---|
| 最低JDK | JDK 5 | JDK 8 | JDK 8 (建议11+) |
| 认证插件 | mysql_native_password | caching_sha2_password + native | 全面支持8.4新插件 |
| TLS支持 | TLS 1.0/1.1 | TLS 1.2/1.3 | TLS 1.3优先 |
| 字符集默认 | utf8mb3 | utf8mb4 (8.0.26+) | utf8mb4_0900_ai_ci |
| X DevAPI | ❌ | ✅ | ✅ 增强型 |
从 8.0.26 开始,Connector/J 的默认字符集连接行为发生了根本性变化,不再自动跟随服务器默认,而是强制使用 utf8mb4 的默认 collation,这直接导致了许多升级后的"Illegal mix of collations"报错。
02. 认证插件陷阱
先看个案例。
Client does not support authentication protocol requested by server
The account running the program uses caching_sha2_password.
场景复现:
当你用旧版 Connector/J 5.1 或早期 8.0 连接 MySQL 8.0+ 实例时,就会触发这个经典错误。原因是 MySQL 8.0 起默认启用 caching_sha2_password,而旧驱动只认识 mysql_native_password。
解决方案有两条:
- 升级驱动(推荐):将 Connector/J 升级到 8.0.22+,原生支持 caching_sha2_password
- 降级认证插件(兼容遗留系统):修改用户认证方式
1 | -- 为遗留应用创建兼容账户 |
JDBC URL 配置示例:
1 | # 8.0.13+ 推荐格式,明确指定认证插件兼容 |
03. TLS 与 JDK 版本:安全传输的硬性门槛
企业级部署中,TLS 版本不匹配是第二个隐形杀手。MySQL 8.4 默认要求 TLS 1.2+,而 JDK 版本直接决定了你能使用的 TLS 级别。
版本对应关系:
- JDK 8u261 以下:仅支持 TLS 1.2,且部分加密套件已被 MySQL 8.4 拒绝
- JDK 8u261:支持 TLS 1.3,但需显式开启
- JDK 8u291:禁用 TLS 1.0 和 1.1
- JDK 8u341:默认启用 TLS 1.3
- JDK 11+:TLS 1.3 默认启用,与 MySQL 8.4 的 SSL 要求完美匹配
实操检查清单:
1 | # 检查当前 JDK 支持的 TLS 版本 |
MySQL 8.4 移除了对 TLS 1.0/1.1 的支持,如果你的应用还在使用 JDK 7 或早期 JDK 8,直接连接会报 SSLHandshakeException,这是升级时必须跨越的第一道门槛。
04. 字符集暗坑:utf8mb4 的 collation
这是笔者在 MySQL 升级过程中踩过的最深的坑。根据资料记录,Connector/J 8.0.25 和 8.0.26+ 在字符集处理上存在破坏性变更。
问题背景:
- 旧数据库默认使用
utf8mb4_general_ci - MySQL 8.0+ 默认使用
utf8mb4_0900_ai_ci(更精准的 Unicode 9.0 排序)
注意,当连接字符集与表字符集不一致时,会产生 “Illegal mix of collations” 错误。
解决方案:在 JDBC URL 中显式指定 connectionCollation:
1 | # 强制使用 general_ci 保持与旧系统兼容(迁移期临时方案) |
验证查询:
1 | -- 检查实际连接使用的 collation |
05. 升级路线图:8.0 到 8.4 的驱动策略
如果你的生产环境正在从 MySQL 8.0 升级到 8.4 LTS,Connector/J 也需要同步规划。
推荐升级路径:
- 当前使用 5.1.x:立即升级到 8.0.33+,先解决认证和 TLS 问题
- 当前使用 8.0.x (低于 8.0.26):升级到 8.0.33 或 8.x/9.x,注意字符集变更
- 全新 8.4 部署:直接使用 Connector/J 8.4.0 或者 9.x,支持新的
explain_json_format_version=2等特性
升级验证脚本:
1 | // 检查驱动版本和服务器版本兼容性 |
06. 总结
好了,本期内容先到这里,简单做个总结。
- 认证先行:MySQL 8.4 时代必须确保 Connector/J 支持 caching_sha2_password,5.1 驱动已彻底退出历史舞台
- 字符集显式化:8.0.26+ 驱动的 collation 行为已变,生产环境务必显式设置
connectionCollation避免混用错误 - TLS 1.3 就绪:JDK 8u261+ 是底线,建议直接迁移到 JDK 11 或 21 以获得完整的 TLS 1.3 和性能优化支持
- 版本对齐:MySQL 8.4 LTS 建议搭配 Connector/J 8.4.x,以获得 JSON Duality Views 等最新特性支持
一句话,如果你安装了 MySQL 8.4 LTS 或者 9.x,直接选择最新版本的 MySQL Connector/J 9.6.0。
Have a nice day ~ ☕
🌻 近期内容 ▼
- Oracle Skills开源:AI工程正在进入"技能时代"
- 苦等三年!Oracle AI Database 26ai本地服务器版终于来了
- MySQL 8.0结束生命周期,8.4.9 LTS、9.7.0发版上线:一个时代的交接与新生
👉 这里有得聊
如果对国产基础软件(操作系统、数据库、中间件)、AI、Vibe Coding、OpenClaw 、Hermes Agent 等感兴趣,可以加群一起聊聊。关注微信公众号:(少安事务所),后台回复[群],即可看到入口。如果这篇文章为你带来了灵感或启发,请帮忙『点赞、推荐、转发』吧,感谢!ღ( ´・ᴗ・` )~
Author: Shawn Yan
Link: https://shawnyan.cn/2026/mysql/mysql-driver-connector-j-9-6-guide/index.html
License: All articles on this site are original unless otherwise stated. Please indicate the source when reprinting!