MySQL 8.0 本身不提供连接池，所谓“配置 MySQL 连接池”实为配置客户端驱动或中间件（如 HikariCP、SQLAlchemy）；减少握手开销的关键是复用连接并启用 TLS 会话复用（Session Resumption），因 MySQL 8.0 默认 caching_sha2_password 插件+未启用 TLS 复用会导致单次建连耗时 30–100ms，远超 SQL 执行时间。
MySQL 8.0 本身不提供连接池，所谓“配置 MySQL 连接池”，实际是配置你用的客户端驱动或中间件（如 HikariCP、sqlalchemy、mysql2 + generic-pool），而减少握手开销的关键，在于复用连接 + 启用 TLS 会话复用（Session Resumption）。
为什么频繁握手在 MySQL 8.0+ 特别明显？
MySQL 8.0 默认启用 caching_sha2_password 插件，认证流程比旧版 mysql_native_password 多一次往返；若再叠加 TLS 加密（尤其未启用会话复用），单次建连可能耗时 30–100ms。高并发下，这比 SQL 执行还慢。
常见错误现象：Communications link failure 频发但网络正常；SHOW PROCESSLIST 里大量 Connecting 状态；应用线程卡在 mysql_real_connect 或 Driver.connect()。
- 必须确认你的客户端驱动支持 MySQL 8.0 认证协议（例如 Java 用
mysql-connector-java 8.0.28+，Python 用pymysql 1.0+或mysqlclient 2.1+） - 若强制降级为
mysql_native_password，虽能绕过部分握手开销，但牺牲安全性，不推荐 - TLS 握手开销远大于认证——哪怕只开 SSL，没启用会话复用，每次建连都走完整 RSA/ECDHE 流程
如何启用 TLS 会话复用（Session Resumption）？
MySQL 8.0.29+ 原生支持 TLS 会话复用，但需服务端和客户端协同开启，否则无效。
服务端检查与配置：
SHOW VARIABLES LIKE 'tls_version'; SHOW VARIABLES LIKE 'ssl_session_cache_mode'; -- 应为 ON SHOW VARIABLES LIKE 'ssl_session_cache_timeout'; -- 默认 300 秒，可调大
客户端启用方式（以常见语言为例）：
- Java（HikariCP + mysql-connector-j）：在 JDBC URL 中加
&enabledTLSProtocols=TLSv1.3&useSSL=true&requireSSL=true，并确保服务端已配好证书且ssl_session_cache_mode=ON - Python（PyMySQL）：传参
ssl={'check_hostname': False, 'ca': '/path/to/ca.pem'}，同时服务端需启用会话缓存 - Node.js（mysql2）：选项中设
ssl: { rejectUnauthorized: false }，并确认底层 OpenSSL 支持 session reuse（v1.10+ 默认开启）
验证是否生效：抓包看第二次连接是否跳过 ServerHello → Certificate → ServerKeyExchange 等步骤，只走 ChangeCipherSpec + Finished。
HikariCP / SQLAlchemy 等连接池如何配合减少握手？
连接池本身不减少单次握手耗时，但它让「一次握手 → 多次复用」成为可能。关键参数不是堆数量，而是控制连接生命周期与健康度：
-
maximumPoolSize（HikariCP）或max_overflow（SQLAlchemy）：设为 10–25，超过 30 易引发锁竞争，反而降低吞吐 -
connectionTimeout：必须缩到1000–3000ms，避免 DNS 卡顿拖垮整个池 -
maxLifetime：设为1800000（30 分钟）或3600000（1 小时），强制重建连接，防止因服务端wait_timeout断连后返回失效连接 -
connectionTestQuery（HikariCP）或pool_pre_ping=True（SQLAlchemy）：必须启用，用SELECT 1或isValid()检测连接有效性，否则复用断连连接直接报错
注意：minIdle 不要设太高（如 >10），空闲连接长期不活动，大概率被 MySQL 主动 kill，反而增加下次获取时的重连概率。
连接池配置后仍出现握手延迟，怎么排查？
最常被忽略的是 DNS 解析和 TCP 层问题，而非 MySQL 协议本身：
- 检查客户端是否启用了 IPv6：MySQL 默认监听
::1和127.0.0.1，若应用优先解析 IPv6 地址但本地未配通，会卡在connect()超时后 fallback 到 IPv4 - 确认
/etc/hosts里有没有错误映射（比如把localhost指向一个不可达的 IPv6 地址） - 用
tcpdump -i lo port 3306抓包，看三次握手是否完成、ServerHello 是否发出、ClientKeyExchange 是否响应——如果卡在某一步，说明是 TLS 或认证环节，不是池配置问题 - MySQL 服务端日志里搜
Aborted connection，高频出现说明连接未正常关闭，可能是应用忘记conn.close()或池未正确归还
真正起作用的从来不是“把池子设多大”，而是让每个连接活得够久、用得够稳、断了能及时发现——握手只发生一次，但连接若反复失效，就等于每次都重新握手。
