开启SSL后性能下降是必然的，源于TLS握手（至少2次RTT）和AES加解密的CPU开销；100并发下TPS实测降约16%，短连接场景因频繁重协商进一步放大开销，需通过长连接+连接池、启用ssl_session_cache、选用AES-GCM套件及规范证书路径权限来优化。
开启SSL后性能下降是必然的，不是配置错了，而是加密解密本身就要吃CPU。实测100并发下TPS下降约16%，这不是bug，是安全换来的代价。
为什么每次连接都慢：TLS握手开销被放大
MySQL每次新建连接都要走完整TLS握手（至少2次RTT），数据传输时还要实时AES加解密——这两个操作强依赖CPU，尤其在短连接、高并发场景下，开销会被显著放大：
- ssl_session_cache未启用或太小，导致频繁重协商；每秒上百次握手会直接拖垮CPU
- 客户端用
mysql -h host -u user -p这种命令行直连，每次都是全新SSL握手 - 应用没配连接池，或连接池最大空闲时间设得太短（比如
maxIdleTime=30000），连接反复销毁重建
为什么cipher选错反而更卡：现代CPU对AES-NI有硬加速
MySQL 8.0默认启用TLSv1.2+和ECDHE密钥交换，安全性提升的同时计算成本也上升。但真正影响性能的是cipher是否匹配硬件能力：
- 别用
DES-CBC-SHA这类老旧套件——它不支持AES-NI，纯软件计算，比AES慢3–5倍 - 优先指定带
AES256-GCM或AES128-GCM的套件，如：ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 - 确认当前生效协议：
SHOW VARIABLES LIKE 'tls_version';，返回TLSv1.2,TLSv1.3就别强行降级到TLSv1.0
为什么证书路径和权限不对会导致隐性延迟
MySQL进程读取server-key.pem失败时，不会报明显错误，但会反复重试，造成连接延迟肉眼可见：
- 私钥文件必须属主为
mysql用户，权限严格为600（ls -l /var/lib/mysql/server-key.pem输出中不能有group/other可读位） - 配置里别写相对路径：
ssl-key = server-key.pem容易出问题，要写绝对路径：ssl-key = /var/lib/mysql/server-key.pem - 检查证书有效期：
openssl x509 -in /var/lib/mysql/server-cert.pem -text -noout | grep "Not After"
真正决定性能上限的其实是连接模式
SSL本身带来的开销是固定的，但连接复用程度决定了这个开销被摊薄还是被放大：
- 长连接+连接池是刚需，比如Java用HikariCP时设
maximumPoolSize=50、idleTimeout=600000，避免频繁建连 - 禁用
skip-name-resolve能省掉DNS解析耗时，但要注意所有GRANT语句必须用IP而非主机名 - 如果业务允许，对内网低敏链路可考虑用
require_secure_transport=OFF+REQUIRE SSL按用户粒度控制，而非全局强制
最容易被忽略的一点：性能瓶颈往往不在SSL配置本身，而在连接生命周期管理。你看到的“SSL变慢”，大概率是应用层没复用连接，让本该摊在1000次请求上的握手成本，分散到了1000次独立连接上。
