开启ssl后性能下降是必然的，实测100并发下tps下降约16%，源于tls握手和aes加解密的cpu开销；优化需聚焦连接复用、高效密码套件、证书权限与路径规范，并优先采用长连接+连接池模式。
开启SSL后性能下降是必然的，不是配置错了，而是加密解密本身就要吃CPU。实测100并发下TPS会掉约16%，这不是bug，是安全换来的代价。
SSL握手和加解密开销直接拉低吞吐量
每次连接建立都要走TLS握手（至少2次RTT），数据传输时还要实时AES加解密。这俩操作都强依赖CPU，尤其在高并发短连接场景下，开销会被放大：
-
ssl_session_cache没开或太小，导致频繁重协商——每秒上百次握手直接拖垮CPU - 用
ssl-cipher指定老旧套件（如DES-CBC-SHA）反而更慢，现代CPU对AES-NI指令集优化更好 - 客户端没复用连接，
mysql -h host -u user -p这种命令行直连，每次都是全新SSL握手
MySQL 8.0默认TLS版本和cipher套件更严，但未必更快
8.0默认启用了TLSv1.2+和更强的密钥交换算法（如ECDHE），安全性提升的同时，计算成本也上升：
- 确认当前实际启用的协议：
SHOW VARIABLES LIKE 'tls_version';，如果返回TLSv1.2,TLSv1.3，别强行降级到TLSv1.0 - 查活跃连接用的cipher：
SELECT * FROM performance_schema.status_by_thread WHERE VARIABLE_NAME = 'Ssl_cipher'; - 想平衡性能与安全，可限定高效套件：
ssl-cipher = 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'
证书文件权限和路径错误会导致隐性降速
MySQL进程读取server-key.pem时若权限不对（比如root写、mysql用户不可读），会反复失败重试，日志里不一定报错，但连接延迟肉眼可见：
- 必须确保
ssl-cert和ssl-key指向的文件属主是mysql用户，权限为600 - 路径别用相对路径，
ssl-cert = /var/lib/mysql/server-cert.pem比ssl-cert = server-cert.pem更稳 -
ls -l /var/lib/mysql/*.pem输出中，私钥文件不能有group/other可读位
真正影响性能的往往不是“该不该开SSL”，而是连接模式——长连接+连接池能抹平80%的SSL开销；而单次查询就新建连接，等于把加密成本摊到每一行结果上。这点容易被忽略，但比调cipher参数实在得多。
