mysql 8.0升级后密码策略未生效，主因是default_authentication_plugin仍为mysql_native_password；需修改my.cnf设为caching_sha256_password并重启，新用户才启用，旧用户须alter user显式切换；validate_password插件仅对set/create/alter user中的新密码校验有效，且参数需写入配置文件持久化；客户端兼容问题可通过alter user切回mysql_native_password临时解决；aes加密解密失败多因字符集变更或存储类型不匹配，应确保列类型为varbinary并显式处理字符集与加密模式。
MySQL 8.0 升级后密码策略没生效？检查 default_authentication_plugin
升级到 MySQL 8.0 后，sha256_password 或 caching_sha256_password 不自动启用，根本原因常是 default_authentication_plugin 仍为 mysql_native_password。这会导致新用户仍用旧加密方式，且 validate_password 插件策略对它们无效。
- 运行
SHOW VARIABLES LIKE 'default_authentication_plugin';确认当前值 - 若不是
caching_sha256_password，需在配置文件my.cnf的[mysqld]段添加：default_authentication_plugin = caching_sha256_password
- 重启 MySQL 后，新创建的用户（如
CREATE USER 'u'@'%' IDENTIFIED BY 'p';）才默认使用新认证插件 - 已有用户不会自动迁移，必须显式修改：
ALTER USER 'u'@'%' IDENTIFIED WITH caching_sha256_password BY 'p';
validate_password 插件加载了但策略不触发？确认插件状态与用户作用域
validate_password 插件只在校验 SET PASSWORD、CREATE USER、ALTER USER 中的密码时生效，且仅对新设或重置的密码起作用——它不扫描已有弱密码，也不干预客户端连接过程。
- 检查是否已安装：
SHOW PLUGINS;中查看validate_password状态是否为ACTIVE - 若未加载，执行：
INSTALL PLUGIN validate_password SONAME 'validate_password.so';（Linux）或validate_password.dll（Windows） - 关键参数需显式设置，例如：
SET GLOBAL validate_password.policy = MEDIUM;<br>SET GLOBAL validate_password.length = 12;<br>SET_GLOBAL validate_password.mixed_case_count = 1;
- 这些变量默认不持久化，务必写入
my.cnf的[mysqld]段，否则重启即失效
客户端连不上：caching_sha256_password 兼容性问题怎么绕过
老版本 MySQL 客户端（如 mysql 5.7 命令行、某些 JDBC 驱动旧版）不支持 caching_sha256_password，报错典型为：Authentication plugin 'caching_sha256_password' cannot be loaded 或连接超时。
- 临时方案：为特定用户切回兼容模式：
ALTER USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'p'; - 长期建议：升级客户端驱动，例如 JDBC 使用
mysql-connector-java:8.0.28+，并确保连接 URL 包含&serverRSAPublicKeyFile=...或启用allowPublicKeyRetrieval=true（仅调试用，生产禁用） - 注意：
caching_sha256_password在 TLS 加密通道下会降级为更轻量的握手流程；若未启用 TLS，首次连接需传输 RSA 公钥，此时客户端必须支持该流程
加密字段（AES_ENCRYPT）在升级后解密失败？别忽略字符集与填充差异
MySQL 8.0 对 AES_ENCRYPT()/AES_DECRYPT() 的底层实现未变，但默认字符集从 latin1 变为 utf8mb4，若原加密数据以二进制方式存为 VARBINARY 则无影响；但若误存为 VARCHAR 并依赖隐式转换，就可能因 padding 或 collation 导致解密失败。
- 验证存储类型：用
DESCRIBE tbl;确认加密列是VARBINARY(255)而非VARCHAR(255) - 解密前先用
HEX()检查原始值是否被截断或乱码：SELECT HEX(encrypted_col) FROM tbl LIMIT 1; - 避免隐式转换：显式指定加密/解密的字符集，例如：
AES_ENCRYPT('text', UNHEX('...'))中密钥也应为二进制，而非字符串 - 注意：MySQL 8.0 默认开启
block_encryption_mode为aes-128-ecb，若旧系统用 CBC 模式，必须显式设置该变量并传入 IV 参数
