MySQL 8.0 强制启用 caching_sha2_password 认证、密码策略、角色权限与事务化数据字典，彻底替代 5.7 的松散模型；旧脚本和客户端若未适配将直接连接或授权失败。
MySQL 8.0 默认启用更强的身份认证与更严格的权限模型，5.7 的默认配置在 8.0 下多数已不兼容或被禁用——这不是“可选增强”，而是强制升级带来的安全基线跃迁。
caching_sha2_password 成为唯一默认认证插件
MySQL 8.0 彻底弃用 mysql_native_password，所有新创建用户默认使用 caching_sha2_password。该插件要求：
- 连接必须走 TLS 加密，或客户端支持 RSA 密钥对进行密码交换（未加密连接下）
- 旧版客户端（如 MySQL 5.7 客户端、部分 JDBC 驱动老版本）若未显式指定 allowPublicKeyRetrieval=true 且未启用 SSL，会直接报错 Public Key Retrieval is not allowed
- 若强制降级回 mysql_native_password，需在创建用户时显式指定：CREATE USER 'u'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';，但此举绕过安全基线，不建议生产环境使用
账户密码策略与生命周期管理落地
MySQL 8.0 原生支持细粒度密码策略，5.7 完全缺失：
- 可设置最小长度：validate_password.length = 12
- 强制包含大小写字母、数字、特殊字符：validate_password.policy = STRONG
- 密码过期：ALTER USER 'u'@'%' PASSWORD EXPIRE INTERVAL 90 DAY;
- 历史密码禁止复用：validate_password.reuse_history = 5
- 注意：validate_password 插件在 8.0 中默认未安装，需手动执行 INSTALL PLUGIN validate_password SONAME 'validate_password.so'; 启用
权限系统重构：角色（ROLE）成为一级对象
5.7 中的“权限集合”只能靠人工维护 SQL 脚本模拟，8.0 提供原生角色管理：
- 创建角色：CREATE ROLE 'app_reader';
- 授权给角色：GRANT SELECT ON sales.* TO 'app_reader';
- 将角色赋给用户：GRANT 'app_reader' TO 'dev1'@'%';
- 激活角色需显式执行：SET ROLE 'app_reader';（或设为默认角色：ALTER USER 'dev1'@'%' DEFAULT ROLE 'app_reader';）
- 角色可嵌套，但循环依赖会被拒绝；DROP ROLE 会自动回收其所授全部权限，避免残留
数据字典与权限元数据彻底事务化
MySQL 8.0 的数据字典存储在 InnoDB 表中（如 mysql.role_edges、mysql.password_history），而非 5.7 的 MyISAM 元数据文件：
- 权限变更（GRANT/REVOKE）现在是原子操作，崩溃后不会出现“权限已写入磁盘但未生效”的中间态
- FLUSH PRIVILEGES 在 8.0 中已完全失效（执行无报错但无作用），权限缓存由服务端自动同步
- 通过 performance_schema.role_edges 可实时查角色继承关系，而 5.7 只能靠解析 SHOW GRANTS 输出
真正容易被忽略的是：MySQL 8.0 的安全增强不是“多了一个开关”，而是整个权限生命周期（创建→授权→验证→审计→回收）都绑定在事务引擎上。一旦沿用 5.7 的运维脚本（比如定期 FLUSH PRIVILEGES、用 mysqldump --all-databases 备份权限、或硬编码 mysql_native_password 连接串），大概率会在上线后某天突然中断——不是性能问题，是连接或授权直接失败。
