开启ssl后性能下降是正常现象，源于tls握手和aes加解密的cpu开销；实测100并发下tps下降约16%，优化关键在于连接复用、高效密码套件、证书权限与路径规范，并优先采用长连接+连接池模式。
开启SSL后连接性能下降是正常现象，不是配置错误，而是加密握手和加解密本身就要消耗CPU资源。实测100并发下TPS会下降约16%，关键不在“能不能开”，而在于“怎么开才不拖慢业务”。
SSL握手开销远超加解密本身
每次新建连接都要走完整TLS握手（至少2次RTT），在短连接场景下，这个开销会被急剧放大：
-
ssl_session_cache未启用或设得太小（如默认的none），会导致每秒上百次重协商，直接打满CPU - 客户端用
mysql -h host -u user -p这种命令行直连，等于每次查询都新建SSL连接，把加密成本摊到每一行结果上 - MySQL 8.0默认启用ECDHE密钥交换，安全性更高，但计算强度也比RSA高——尤其在无AES-NI指令集的老CPU上更明显
证书路径与权限问题引发隐性延迟
证书文件读取失败不会报错，但会反复重试，造成连接卡顿，日志里往往看不到线索：
- 私钥文件
server-key.pem必须属主为mysql用户，权限严格为600；ls -l /var/lib/mysql/server-key.pem输出中不能有group/other可读位 - 配置中必须用绝对路径，
ssl-key = /var/lib/mysql/server-key.pem比ssl-key = server-key.pem可靠得多 - 相对路径或权限不对时，MySQL进程会静默降级为非SSL连接，但客户端仍按SSL流程等待，导致超时感
cipher套件选错反而更慢
不是“越强越安全=越慢”，而是要匹配硬件能力。老旧套件（如DES-CBC-SHA）在现代CPU上效率远低于AES-GCM：
- 优先用支持AES-NI的套件：
ECDHE-ECDSA-AES256-GCM-SHA384或ECDHE-RSA-AES256-GCM-SHA384 - 禁用低效算法：在
my.cnf中显式指定ssl-cipher，避免MySQL自动 fallback 到慢套件 - 确认实际生效协议：
SHOW VARIABLES LIKE 'tls_version';应为TLSv1.2,TLSv1.3；查当前连接用的套件：SELECT * FROM performance_schema.status_by_thread WHERE VARIABLE_NAME = 'Ssl_cipher';
真正有效的优化几乎都绕不开连接复用
调参数能省10%~20%开销，但长连接+连接池能抹平80%以上的SSL损耗。这点最容易被忽略，却最实在：
- Web应用务必用连接池（如HikariCP、Druid），设置
min-idle和max-active合理值，避免频繁建连 - 命令行调试时加
--ssl-mode=REQUIRED而非反复启停，或改用mysql --defaults-file=...复用配置 - 临时验证影响？用
mysql --ssl-mode=DISABLED -h host -u user -p对比耗时，别只看错误日志
SSL性能损耗无法归零，但可以控制在可接受范围——重点从来不是压榨cipher或降级TLS版本，而是让连接尽可能“活久一点”。
