MySQL 5.7 不支持多因素身份验证（MFA），因 authentication_policy 等核心特性自 8.0.27 起才引入；若需 MFA 效果，可借助 PAM 插件、SSH 隧道或应用网关代理实现，但均属外部补位，非原生支持。
authentication_policy、--password2 或 authentication_fido 插件的操作都会失败，因为这些特性从 MySQL 8.0.27 才正式引入。
如果你正在用 5.7，又需要类似 MFA 的效果，只能靠外部机制补位。下面分场景说明怎么做、为什么这么做、以及最容易翻车的地方。
为什么直接 upgrade 到 8.0 是最省事的路径
MySQL 5.7 的认证体系是单因素硬编码的：mysql_native_password 或 sha256_password，没有插件链、没有 factor slot、也没有 ALTER USER ... REQUIRE MULTIFACTOR 语法。你改配置、装插件、甚至编译源码，都无法绕过这个限制。
而 MySQL 8.0.27+ 原生支持三因素组合：*, authentication_ldap_sasl, authentication_fido，且 authentication_policy 可动态控制策略。升级后只需两步：
- SET GLOBAL authentication_policy = '*,authentication_ldap_sasl,';
- CREATE USER 'alice'@'%' IDENTIFIED BY 'p1' REQUIRE MULTIFACTOR;
在 5.7 上模拟 MFA 的三种可行方案
生产环境若暂时无法升级，可选以下任一方式“逼近”MFA 效果，但要注意每种方案的边界：
-
PAM 插件 + 系统级双因素：仅限 MySQL Enterprise 或 Percona Server 支持
authentication_pam插件；需配置/etc/pam.d/mysql加入pam_google_authenticator.so；用户必须用IDENTIFIED WITH authentication_pam创建；客户端连接时仍只输一次密码，第二因素由 PAM 在系统层拦截验证——这意味着 MySQL 自身完全不知情，日志里也看不到 factor 验证结果。 -
SSH 隧道 + 本地 socket 访问：把 MySQL 绑定到
127.0.0.1，禁用所有远程 TCP 连接；在跳板机或 DB 服务器上启用 SSH 双因素（如 Google Authenticator）；用户必须先 SSH 登录，再执行mysql -S /var/run/mysqld/mysqld.sock；这本质是把第二因素移到了网络入口层，MySQL 连接本身仍是单因素，但攻击面大幅收窄。 -
应用网关代理验证：在应用和 MySQL 之间加一层代理（如 ProxySQL 或自研服务），由代理完成 TOTP/SMS/证书等第二因素校验，再以固定内部账号（如
app_backend@localhost）连接 MySQL；此时数据库看到的永远是可信内网连接，所有 MFA 逻辑都在代理层实现——但要求所有流量必须经代理，不能直连。
容易被忽略的权限与日志盲区
无论选哪种方案，有三个点常被漏掉：
-
require_secure_transport = ON必须开启——否则 PAM 或代理验证后的连接可能被中间人降级为明文，让前面所有努力归零； - MySQL 5.7 的
general_log和slow_query_log默认不记录认证失败原因，查不到 “TOTP 错误” 或 “PAM 拒绝”，只能靠系统日志（/var/log/secure）或代理自身日志排查； - 如果用了 PAM，
mysql用户必须属于pam_wheel组（或对应 PAM 规则允许的组），否则即使配置正确，也会静默拒绝认证，错误日志只显示Access denied for user，无任何线索。
