MySQL 8.0.16+ 才支持通过 tls_version 配置禁用旧 TLS 版本，低于该版本该变量只读且配置无效；必须在 my.cnf 的 [mysqld] 段设 tls_version = TLSv1.2,TLSv1.3（无空格），并启用 require_secure_transport = ON，重启 mysqld 后通过 STATUS 或 performance_schema 验证实际协商版本。
MySQL 8.0.16+ 才能真正禁用旧 TLS 版本
低于 MySQL 8.0.16 的版本，tls_version 变量只读，写进 my.cnf 也无效；改了配置，mysqld 启动时会忽略或报错。必须先确认版本：SELECT VERSION(); 和 SELECT @@version_compile_ssl; —— 后者告诉你实际链接的 OpenSSL 版本，它决定了底层支持范围。
配置 tls_version 必须无空格、逗号分隔
在 my.cnf 的 [mysqld] 段中写：
tls_version = TLSv1.2,TLSv1.3
注意以下几点：
-
tls_version值里**不能有空格**，TLSv1.2, TLSv1.3（带空格）会导致mysqld启动失败 - MySQL 8.0.28+ 已彻底移除对
TLSv1和TLSv1.1的支持，即使你写进去也会被静默忽略 - 若只配
TLSv1.3，客户端需满足：OpenSSL ≥ 1.1.1、Java ≥ 11、Python ≥ 3.10，否则握手直接失败，报错SSL connection error: Unsupported protocol - 改完必须重启
mysqld，SET GLOBAL tls_version = ...不生效
require_secure_transport = ON 是强制前提
光设 tls_version 不够——它只限制“可用协议范围”，不阻止明文连接。必须同时启用：
require_secure_transport = ON
否则，哪怕服务端全配好了，客户端不加 --ssl-mode=REQUIRED，照样走明文。这个开关才是拦截非加密连接的硬闸。
常见误判点：
- 旧客户端（如某些 MySQL 5.7 默认编译版）可能因缺失 SSL 库，连上就报
SSL connection error: protocol version mismatch，不是服务端没配好，而是客户端根本不支持协商 - 证书路径权限不对（如
ssl_ca文件被mysql用户读不到），require_secure_transport = ON会静默失效，连接仍可建立但不加密
验证是否真禁用了 TLSv1.1
SHOW GLOBAL VARIABLES LIKE 'tls_version'; 只说明“服务端允许哪些”，不代表当前连接用了哪个。关键要看实际协商结果：
- 连接后执行
STATUS;，找输出中SSL:行，例如SSL: Cipher in use is ECDHE-RSA-AES256-SHA→ 对应 TLSv1.2；TLS_AES_256_GCM_SHA384→ TLSv1.3 - 或查性能表：
SELECT VARIABLE_VALUE FROM performance_schema.status_by_thread WHERE THREAD_ID = CONNECTION_ID() AND VARIABLE_NAME = 'Ssl_version'; - 用
openssl s_client -connect host:3306 -tls1_1主动测试：如果返回handshake failed或超时，说明 TLSv1.1 确实被拒
最容易被忽略的是客户端行为——服务端再严，只要客户端不声明加密需求（比如没加 --ssl-mode=REQUIRED），连接就永远是明文的。
