MySQL 8.0+ 的 authentication_policy 不能真正启用标准MFA，它仅支持同一用户在不同连接上下文启用多个认证插件，并非联合验证；真正接近MFA的是密码+客户端证书组合，需手动配置REQUIRE SUBJECT/ISSUER/CIPHER并强制SSL。
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';
关键点：
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
-
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
真正的风险点不在功能有没有，而在证书怎么分发、密码策略谁来审计、日志谁有权删——这些环节一旦脱钩，再全的认证选项也只是装饰。
