ssl连接慢的根本原因是tls握手开销和算法选择，而非网络延迟；需服务端配置ssl-cipher、ssl_session_cache、tls_version并配合客户端连接池复用，才能有效减少握手次数、降低50–200ms单次延迟。
SSL连接慢不是网络问题，是握手开销和算法选择导致的
MySQL 8.0 启用 SSL 后连接变慢，90% 的情况不是带宽或延迟问题，而是 TLS 握手阶段的计算与协商耗时。哪怕本地 127.0.0.1 连接，只要客户端显式启用 SSL（如连接串含 ?ssl-mode=REQUIRED），服务端就会执行完整握手流程：证书校验、密钥交换、会话恢复判断等。实测中，单次 SSL 连接比非 SSL 多出 50–200ms，高并发下积少成多，TPS 下降 10%–20% 是常态。
如何验证确实是 SSL 导致的延迟
用最简方式隔离问题：
- 临时禁用 SSL 连接测试：
mysql -h 127.0.0.1 -u root -p --ssl-mode=DISABLED，对比耗时 - 开启慢日志并抓取连接阶段：
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 0.1;，然后看是否大量Connect事件被记录 - 检查服务端是否真在用 SSL：
SHOW STATUS LIKE 'Ssl_cipher';返回非空值才说明握手已发生
必须改的三个配置项：cipher、session cache、protocol version
只靠硬件升级或调大 buffer 无法缓解 SSL 握手瓶颈，关键在协议层精简：
-
ssl-cipher=AES256-SHA256：避免使用 RSA 密钥交换（已淘汰），优先选 ECDHE 套件，但 MySQL 8.0 对ECDHE-ECDSA支持不稳定，AES256-SHA256兼容性好且性能可接受 -
ssl_session_cache = 1m和ssl_session_timeout = 10m：启用会话复用，让重复连接跳过完整握手；注意该缓存仅对同一客户端 IP + 端口有效，连接池复用才能真正受益 -
tls_version = TLSv1.2,TLSv1.3：MySQL 8.0.28+ 支持 TLSv1.3，握手轮次更少；若版本较低，至少禁用TLSv1.0和TLSv1.1（已在 RFC 8996 中废弃）
容易被忽略的客户端行为：连接池没配对，等于白优化
服务端开了 session cache，但客户端每次新建连接、不复用 socket，那缓存毫无意义。常见坑点：
- Java 应用用 HikariCP，必须设
connection-test-query=SELECT 1且max-lifetime>ssl_session_timeout，否则连接被回收后重连仍要握手 - Python 的
pymysql默认不复用连接，要用ConnectionPool或aiomysql配合 asyncio pool - Node.js 的
mysql2需显式传connectTimeout: 10000和acquireTimeout: 10000，否则超时中断会触发新握手
SSL 性能优化的本质不是“关掉它”，而是让每一次握手尽可能少发生——服务端配置只是半边腿，客户端连接生命周期管理才是另一半。漏掉任意一端，优化就失效。
