MySQL 8.0.28+ 已默认禁用 TLSv1 和 TLSv1.1，无需额外配置；低于该版本需在 my.cnf 的 [mysqld] 段设置 tls_version = TLSv1.2,TLSv1.3（无空格），且仅 8.0.16+ 支持该参数，低版本需升级或通过 OpenSSL 系统级限制（如 MinProtocol = TLSv1.2）强制。
MySQL 8.0.28+ 已默认禁用 TLSv1 和 TLSv1.1，无需额外操作；低于该版本必须手动配置 tls_version 并确认 OpenSSL 底层未放行旧协议，否则仍可能被协商成功。
确认 MySQL 版本是否真正支持 tls_version 配置
低于 8.0.16 的 MySQL 会把 tls_version 当作只读变量，写进 my.cnf 也无效，启动时还会报 warning。执行以下命令验证：
SELECT VERSION();
若返回 8.0.15 或更低，tls_version = TLSv1.2,TLSv1.3 在配置文件中不会生效——你得升级或改用 OpenSSL 系统级限制（如修改 /etc/ssl/openssl.cnf 中的 MinProtocol = TLSv1.2）。
在 my.cnf 中正确设置 tls_version
仅适用于 MySQL 8.0.16 及以上版本。在 [mysqld] 段添加：
tls_version = TLSv1.2,TLSv1.3
注意这几点：
-
tls_version值是逗号分隔、无空格的字符串；含空格会导致 mysqld 启动失败 - MySQL 8.0.28+ 会直接忽略
TLSv1或TLSv1.1——即使你写进去也不会报错，但也不起作用 - 修改后必须
systemctl restart mysqld（热加载不生效） - 若只保留
TLSv1.3，要确保客户端 OpenSSL ≥ 1.1.1，否则连接直接失败
验证实际连接是否真的没用 TLSv1/TLSv1.1
SHOW GLOBAL VARIABLES LIKE 'tls_version' 只说明“服务端允许哪些”，不能代表当前连接用了哪个。真正要看的是运行时协商结果：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
STATUS;
在输出里找 SSL: 行，例如：
SSL: Cipher in use is TLS_AES_256_GCM_SHA384
这表示实际用了 TLSv1.3；如果看到 SSL: Not in use，说明根本没走加密通道，跟 tls_version 无关。更精确的方式是查性能模式：
SELECT VARIABLE_VALUE FROM performance_schema.status_by_thread WHERE VARIABLE_NAME = 'Ssl_version' AND THREAD_ID = CONNECTION_ID();
返回值应为 TLSv1.2 或 TLSv1.3，绝不能是 TLSv1 或 TLSv1.1。
客户端不配合，服务端设了也白设
常见握手失败不是因为服务端没配好，而是客户端能力或配置没跟上：
- MySQL 命令行工具必须加
--ssl-mode=REQUIRED，否则默认走明文 - Java 应用 JDBC URL 要带
&enabledTLSProtocols=TLSv1.2，且 JDK ≥ 8u161；旧版mysql-connector-java 默认禁用 TLSv1.2+ - Python 的
pymysql必须显式传ssl={'tls_versions': ['TLSv1.2']}，否则会 fallback 到最低可用版本（可能就是 TLSv1.0） - OpenSSL 1.0.2 编译的客户端无法协商 TLSv1.3，哪怕服务端只开了它，也会握手失败并报
SSL connection error: Unsupported protocol
最易被忽略的一点：系统级 OpenSSL 配置（如 /etc/ssl/openssl.cnf）中的 MinProtocol 和 MaxProtocol 会覆盖 MySQL 的 tls_version 设置，必须一并检查。
