升级到 MySQL 8.0+ 之后连不上?遇到这种 MySQL 8.0 连接失败问题,十有八九不是数据库配置的锅,而是客户端还在沿用旧方案——驱动类和连接参数都没跟上协议更新。这个 JDBC 驱动不兼容问题在技术社区已被反复讨论,但真正排查时,仍需一步步把关键环节梳理清楚。

MySQL 8.0+ 连接失败,90% 的根源在于仍沿用 mysql-connector-ja va-5.x 驱动,或未更新连接参数——数据库本身并无问题,是客户端的通信协议和认证方式已经不再兼容。
com.mysql.jdbc.Driver 报 ClassNotFoundException 如何解决
这个类在 MySQL 8.0+ 驱动中已被彻底移除。如果你的老项目里硬编码了 com.mysql.jdbc.Driver,或者在 application.yml、db.properties 等配置文件中引用了它,必须全部替换为 com.mysql.cj.jdbc.Driver。
- 检查 classpath 下的 JAR 文件名:确认是
mysql-connector-ja va-8.x.x.jar或mysql-connector-j-8.x.x.jar(推荐使用 8.3.0+ 版本),切勿沿用mysql-connector-ja va-5.1.49.jar这类旧版 - Maven 依赖需彻底移除旧版本,替换为:
mysql
mysql-connector-j
8.3.0 - 代码中
Class.forName("com.mysql.jdbc.Driver")这类传统写法,建议直接移除——新版驱动通过 SPI 机制自动注册,手动加载反而可能引发警告,多此一举
连接成功却查不出数据或提示时区/字符集异常
仅替换驱动类名远远不够。MySQL 8.0 默认强制校验时区、默认采用 utf8mb4 字符集、默认开启 SSL 要求,旧连接串缺少参数会导致静默失败:应用虽能启动,Connection 对象也能创建,但首次执行 executeQuery 时就卡住或返回空结果,排查难度极大。
- 完整连接 URL 至少需要包含以下四个参数:
?serverTimezone=Asia/Shanghai&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true serverTimezone不能留空或随意写个UTC了事——业务时间逻辑依赖本地时区,使用Asia/Shanghai更为可靠characterEncoding=utf8并非可有可无:虽然 MySQL 8.0 默认字符集为utf8mb4,但驱动若不声明,某些中文字段会被截断,甚至报Incorrect string value错误useSSL=false在开发环境中必须添加;生产环境应配置证书并设为true,否则连接可能被拒绝,安全扫描也会触发告警allowPublicKeyRetrieval=true是 8.0.4+ 版本的强制要求,否则 RSA 密钥交换阶段直接卡死
MyBatis 分页查询或 IN 条件失效、返回空结果集
这并非 SQL 编写有误,而是预编译语句缓存行为发生了变化。旧驱动默认开启 cachePrepStmts=true,新驱动若不显式配置缓存大小则会降级为禁用,导致 ORM 动态 SQL 回退成普通语句执行,触发权限限制或语法不兼容。
- 在连接 URL 中补充:
&cachePrepStmts=true&prepStmtCacheSize=250&prepStmtCacheSqlLimit=2048 - 尤其影响
IN (?, ?, ?...)列表过长、LIMIT ?,?分页等场景,不添加可能直接返回空集合,测试时难以察觉 - Spring Boot 用户需注意:
spring-boot-starter-jdbc2.1+ 虽默认内置 8.x 驱动,但若通过将其排除又手动引入 5.x 版本,同样会踩坑
能连接但提示 Plugin caching_sha2_password could not be loaded 错误
这是 MySQL 8.0 默认认证插件变更所致。JDBC 5.x、旧版 Navicat、DBeaver 等客户端根本不识别 caching_sha2_password,即便驱动和 URL 都正确,也会在登录阶段被拒绝。
- 最稳妥的方案:将相应用户切回旧版插件:
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password'; FLUSH PRIVILEGES; - 不建议修改
my.cnf中的default_authentication_plugin:该配置仅影响新创建的用户,已有用户不会自动更新,且重启服务存在风险 - 别轻信“加个
allowPublicKeyRetrieval=true就能绕过”的说法——它解决的是密钥交换问题,而非认证插件不被识别的问题
真正棘手的并非驱动是否更换,而在于每个参数调整都可能引发连锁反应:比如 useSSL=false 虽能建立连接,却可能被安全扫描工具标记为风险项;serverTimezone=Asia/Shanghai 解决了时区错乱,但在跨时区部署场景下仍需动态切换。这些细节若不写入配置、不经真实查询验证,仅凭启动日志根本无法察觉。
