MySQL 8.4 默认强制SSL协商，旧驱动不兼容；根治需服务端配置skip_ssl并重启，确认have_ssl=DISABLED，同时避开8.4.0驱动Bug，改用8.3.0或8.4.5+版本。
MySQL 8.4 默认强制协商 SSL，旧驱动不兼容
MySQL 8.4（含 8.4.0 起所有小版本）服务端默认开启 SSL 协商流程，即使未配置证书，也会在握手阶段发送 SSL 请求包。而旧版驱动（如 mysql-connector-java 5.1.x、6.0.x 或部分未升级的 8.0.2x）既不支持该行为，也未正确处理“服务端提议 SSL 但无证书”的降级逻辑，直接中断连接，表现为 Lost connection to MySQL server at 'handshake' 或日志中高频出现 [Note] Bad handshake。
useSSL=false 在 8.4+ 环境下容易失效的几个原因
加了 useSSL=false 却仍报错，常见于以下情况：
-
useSSL=false写成userSSL=false（拼错参数名），驱动静默忽略 - URL 中多个参数未用
&分隔，例如?useUnicode=true&useSSL=falsecharacterEncoding=utf8，导致characterEncoding被当成了useSSL的值 - 使用了新版驱动（
mysql-connector-j 8.4.0），它已弃用useSSL，改用enabledTLSProtocols=或要求显式配allowPublicKeyRetrieval=true - Spring Boot 2.4+ 默认启用 SSL 校验增强，仅设
useSSL=false不够，必须补上allowPublicKeyRetrieval=true，否则抛SSLHandshakeException
skip_ssl 是最稳的根治方式，但要注意配置位置
服务端禁用 SSL 比客户端绕过更可靠，操作本身简单，但容易出错的地方是：
- 必须在
[mysqld]段落里加skip_ssl，不是[client]或[mysql] - 不能写成
ssl=0、ssl_disabled=1或require_secure_transport=OFF（后者只控制强制要求，不关闭协商） - 改完后必须重启服务：
systemctl restart mysqld（Linux）或 Windows 服务管理器中重启 - 验证是否生效：连上 MySQL 后执行
SHOW VARIABLES LIKE '%ssl%';，确认have_ssl和have_openssl均为DISABLED
MySQL 8.4.0 驱动自身存在 handshake 初始化缺陷
官方已确认 mysql-connector-j 8.4.0 存在驱动层 Bug（Bug #115736），表现是连接初始化时握手阶段卡顿或失败，尤其在高并发下触发 SQLNonTransientConnectionException: Got an error writing communication packets（错误码 1160，SQLSTATE 08S01）。这不是配置问题，而是驱动代码缺陷：
- ARM64 下固定卡 30 秒，Intel 服务器也常超 2 秒
- 影响 Spring Boot 3.2 + JDK21 + HikariCP/Druid 场景
- 官方标记为 S3 级别，状态是
Duplicate（对应 #115586），截至 2026 年 9 月仍未修复 - 临时缓解：降级到
mysql-connector-j 8.3.0或跳过 8.4.0，直接用8.4.5+（但需注意 8.4.5 后报错频率反而升高）
真正要稳定跑 MySQL 8.4，得同时满足三件事：服务端 skip_ssl 关握手协商、客户端驱动版本与参数匹配、避开 8.4.0 这个已知有坑的驱动版本——少一个，都可能在凌晨三点收到告警。
