MySQL 8.0+ 的 authentication_policy
能否真正启用多因素认证？
不能直接启用「标准意义上的 MFA」。MySQL 官方不支持短信/OTP/生物识别等第二因子验证，
authentication_policy是个误导性变量名——它实际只控制「多个认证插件是否可同时启用」，且仅限于同一用户在不同连接上下文（如本地 vs 远程）使用不同插件，并非真正 MFA。
真正接近 MFA 的方案是组合使用：
caching_sha2_password（主因子：密码） +
authentication_ldap_sasl或客户端证书（次因子），但二者需手动串联逻辑，MySQL 本身不校验“两个因子都通过才放行”。 MySQL 8.0.27+ 引入的
authentication_policy只接受
OFF/
ON，设为
ON后允许对同一用户配置多个
IDENTIFIED WITH ... BY ...子句，但登录时仍只匹配第一个满足条件的认证方法 所谓“双因子”实操中常指：应用层先做 LDAP 绑定，再用返回的 token 换取 MySQL 短期账号（类似 OAuth flow），这不是数据库内建能力 若强行在
CREATE USER中写两个
IDENTIFIED WITH，第二个会被忽略，除非用
ALTER USER ... ADD AUTHENTICATION（仅限企业版 8.0.30+，且仍不触发联合验证）
用 require ssl
和客户端证书实现类 MFA 效果
这是最接近生产可用的“双因子”路径：密码（知识因子） + 客户端证书私钥（持有因子）。MySQL 原生支持，无需中间件，但需严格管理证书生命周期。
CREATE USER 'app_user'@'%' IDENTIFIED WITH caching_sha2_password BY 'weakpass' REQUIRE SUBJECT '/CN=app-client/C=CN' AND ISSUER '/CN=MyCA/C=CN' AND CIPHER 'ECDHE-ECDSA-AES256-GCM-SHA384';
关键点：
REQUIRE SUBJECT校验客户端证书 DN，
ISSUER防止伪造 CA，
CIPHER限定 TLS 握手加密套件（避免降级到不安全协议） 必须配合
ssl_mode=REQUIRED在客户端连接参数中显式声明，否则即使服务端要求 SSL，客户端也可能静默降级 证书过期后用户无法登录，但错误提示是
Access denied for user，不是明确的证书失效，排查时容易误判为密码错误
validate_password
插件和 password_history
的真实约束力
它们只管“新密码是否合规”，不管“旧密码是否被重用”或“密码是否泄露”。开启后仍可能因运维习惯（如批量改密脚本硬编码旧密码）导致策略形同虚设。
validate_password.length设为 12 并不能阻止用户设
123456789012—— 插件默认不校验字符多样性，需额外设
validate_password.mixed_case_count=1、
validate_password.number_count=1等
password_history=5仅检查最近 5 次修改记录，若用户用
ALTER USER ... IDENTIFIED BY RANDOM PASSWORD绕过密码输入，历史记录不更新 插件不拦截
SET PASSWORD语句，DBA 仍可用该命令绕过所有策略，权限模型上没隔离“密码策略执行者”和“密码修改者”
审计日志（audit_log
）开不开，差别远不止“有没有日志”
开启后性能下降 5–15%，但更关键的是默认日志格式（JSON）难以直接 grep，且不记录 SQL 语句体（只记语句类型），对溯源攻击价值有限。
必须设置audit_log_policy=ALL才记录 DDL/DML，
audit_log_policy=LOGINS只记连接事件，连谁删了表都看不到 日志文件权限若为
644，任何有服务器 shell 权限的用户都能读取，等于把审计日志变成明文密码本 MySQL 不提供日志轮转自动压缩，
audit_log_file写满磁盘会导致 mysqld crash，需配合外部 logrotate 并发
FLUSH LOGS
真正的风险点不在功能有没有，而在证书怎么分发、密码策略谁来审计、日志谁有权删——这些环节一旦脱钩，再全的认证选项也只是装饰。
