mysql 5.7+账号是否强制ssl由mysql.user表ssl_type字段决定，其为枚举值：''（不强制）、any、x509、specified；仅当非空时生效，且修改后须执行flush privileges才生效。
看 mysql.user 表里的 ssl_type 字段
MySQL 5.7 及以后版本中，账号是否强制要求 SSL，主要由 mysql.user 表的 ssl_type 字段决定。它不是布尔值，而是一个枚举字段，合法值为 ''（空字符串）、ANY、X509、SPECIFIED。只要不是空字符串，就表示该账号启用了 SSL 约束。
执行这条 SQL 就能快速筛查：
SELECT user, host, ssl_type, ssl_cipher, x509_issuer, x509_subject FROM mysql.user WHERE ssl_type != '';
-
ssl_type = 'ANY'：只要求客户端提供有效证书（不校验内容） -
ssl_type = 'X509'：要求客户端提供任意有效 X509 证书，且必须通过 CA 验证 -
ssl_type = 'SPECIFIED'：除证书外，还额外限制了ssl_cipher、x509_issuer或x509_subject中至少一项 -
ssl_type = ''：未启用 SSL 要求（即使其他字段非空，也无效）
ssl_cipher 和 x509_* 字段不能单独判断 SSL 是否生效
这些字段只是辅助条件，本身不触发 SSL 强制行为。比如你只设置了 ssl_cipher = 'TLS_AES_256_GCM_SHA384'，但 ssl_type 是空的，MySQL 完全忽略这个设置，连接仍可走明文。
常见误操作：
- 用
GRANT ... REQUIRE CIPHER ...但没加SSL或X509关键字 →ssl_type仍为空 - 手动 UPDATE
mysql.user表却漏改ssl_type→ 其他字段写入成功，但无实际效果 - 在 MySQL 8.0+ 使用角色（ROLE）赋权时，角色本身的
ssl_type不继承给用户，必须显式对用户执行REQUIRE SSL
MySQL 8.0 的 authentication_policy 不影响 SSL 判断逻辑
虽然 8.0 引入了 authentication_policy 和更细粒度的身份验证控制，但它和传输层加密（SSL/TLS）是正交的两件事。判断账号是否“要求 SSL 连接”，依然只看 mysql.user 表中的 ssl_type 字段，跟认证插件或策略无关。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
注意一个易混淆点：
-
REQUIRE ISSUER '/CN=CA'属于REQUIRE X509的子集，会把ssl_type设为'SPECIFIED'，不是'X509' -
SHOW CREATE USER输出里如果看到REQUIRE SSL或类似子句，说明ssl_type已正确设置；如果完全没出现REQUIRE，基本可以确定没开 SSL 强制
权限表变更后必须执行 FLUSH PRIVILEGES
直接 UPDATE mysql.user 表修改 ssl_type 后，新设置不会立即生效——MySQL server 不会自动监听系统表变化。必须显式执行：
FLUSH PRIVILEGES;
否则即使查 mysql.user 看到值已改，新连接仍按旧规则校验。这也是排查“为什么设了 SSL 却不生效”时最常被跳过的一步。
另外，ssl_type 是 session 级不可变的：一旦连接建立，其 SSL 要求状态就固定了，后续在该连接内做任何 GRANT/UPDATE 都不影响当前会话。
