mysql 5.7权限机制因隐式建用户、弱认证协议、无角色模型及松散表结构而易引发配置风险；8.0通过强制显式用户创建、升级认证插件、引入角色管理和重构权限表结构，实现安全约束的系统化强制。
MySQL 5.7 的权限管理机制不是“更脆弱”，而是缺乏现代安全设计约束，导致实际使用中更容易因配置疏忽、语法宽松或默认策略过松而引入风险。8.0 不是变“强”了，而是把原本靠人肉规避的问题，变成了系统级强制校验。
GRANT 隐式建用户让权限失控成为常态
5.7 允许 GRANT SELECT ON db.* TO 'u'@'%' IDENTIFIED BY 'p' 一条语句完成建用户+赋权，表面方便，实则埋下三类隐患：
- 权限与认证耦合：密码设置和授权混在同一语句，无法单独轮换密码而不影响权限
- 无显式生命周期管理：用户是否存在、是否已过期、是否被禁用，全靠人工查
mysql.user表，FLUSH PRIVILEGES也常被误用 - sql_mode 可开关该行为：若后期启用了
NO_AUTO_CREATE_USER，原有脚本直接失败，但没人知道哪段 SQL 依赖它
8.0 强制拆成 CREATE USER + GRANT，看似麻烦，实则让每个操作意图清晰可审计——建用户是建用户，授权是授权，改密码是改密码。
默认认证插件暴露弱密码传输风险
5.7 默认用 mysql_native_password，明文传输密码哈希（虽非明文密码），且不支持服务端密钥交换优化，旧协议易受中间人重放攻击。8.0 改为 caching_sha2_password 后，即使密码本身弱，协议层也强制做 RSA 加密协商，客户端必须支持才能完成握手。
这不是“功能增强”，而是堵住协议层已知攻击面。你看到的连接失败报错 Authentication plugin 'caching_sha2_password' cannot be loaded，本质是系统在拒绝不安全的通信路径。
角色缺失导致权限复用与回收不可控
5.7 没有 ROLE 概念，批量赋权只能靠循环执行 GRANT ... TO 'u1'@'%'; GRANT ... TO 'u2'@'%';。结果就是：
- 权限变更需遍历所有用户，漏一个就留后门
- 离职人员权限回收靠手动
REVOKE，无法一键撤回“开发组”全部权限 - 无法做权限继承建模（如：DBA > SeniorDev > JuniorDev），只能复制粘贴相同 GRANT 语句
8.0 的 CREATE ROLE 'dev_role'; GRANT SELECT, INSERT ON app.* TO 'dev_role'; GRANT 'dev_role' TO 'alice'@'%'; 把权限抽象成可管理对象，回收时只需 DROP ROLE 或 REVOKE 'dev_role' FROM 'alice'@'%'，行为确定、影响可控。
权限表结构松散，升级后极易静默失效
5.7 的 mysql.user 表含 Password 字段（已弃用）、ssl_type 等冗余字段，权限判断逻辑分散在多个字段组合中；8.0 彻底重构为 authentication_string + plugin + account_locked + password_expired 等原子化字段，每项含义明确、互不干扰。
直接拷贝 5.7 的 INSERT INTO mysql.user 行到 8.0，会因字段缺失或类型不匹配导致插入失败，甚至让 root 用户无法登录——这不是 bug，是设计上拒绝模糊兼容。
真正难处理的不是语法差异，而是 5.7 时代积累的“能跑就行”权限脚本，在 8.0 下不会报错，但可能因默认 strict mode、字符集变更、排序规则差异，让某条 SHOW GRANTS FOR 'u'@'h' 返回结果和预期不一致，而这种偏差往往要等审计或故障时才暴露。
