直接GRANT到用户不再够用，因MySQL 8.0+转向角色驱动：权限难复用、变更需逐用户操作、审计无法追溯业务职责；且新用户授权易因参数或host段错误报ERROR 3530。
为什么直接 GRANT 到用户不再够用
MySQL 8.0+ 的权限模型已转向角色（ROLE）驱动，单用户直授权限（如 GRANT SELECT ON mydb.* TO 'appuser'@'%'）虽仍能运行，但会带来三个硬伤：权限难以复用、变更需逐个用户操作、审计时无法追溯“这组权限属于哪个业务职责”。更关键的是，一旦后续要给新用户配同样权限，就得重复写一遍 GRANT，漏一个参数或 host 段就报 ERROR 3530 (HY000): Cannot grant to role 'xxx' because it does not exist。
创建角色并绑定权限的最小必要步骤
角色不是“用户”，不能登录，它只是权限容器。必须按固定顺序执行，缺一不可：
-
CREATE ROLE 'api_reader'—— 角色名必须带引号，且需显式声明，不能跳过 -
GRANT SELECT, SHOW VIEW ON `myapp`.* TO 'api_reader'—— 权限只授给角色，不涉及 host；数据库名用反引号包裹，避免关键字冲突 -
CREATE USER 'api_user'@'172.%.%.%' IDENTIFIED BY 'pwd_2026'—— 用户必须先建，再授权；host 段建议限制内网段，不用'%' -
GRANT 'api_reader' TO 'api_user'@'172.%.%.%'—— 注意两边的 host 段必须完全一致，否则报错 -
SET DEFAULT ROLE 'api_reader' TO 'api_user'@'172.%.%.%'—— 这步最容易漏，不执行则用户登录后权限为空
升级已有用户时如何避免权限中断
现有用户已用直授方式运行了一段时间，想平滑迁移到角色管理，不能直接 DROP 或 REVOKE 原权限——那会导致服务瞬间失权。正确做法是叠加过渡：
- 先查出当前权限：
SHOW GRANTS FOR 'legacy_user'@'localhost' - 按查得的权限新建角色，例如
CREATE ROLE 'legacy_ro'+GRANT SELECT ON prod_db.* TO 'legacy_ro' - 把角色授给原用户：
GRANT 'legacy_ro' TO 'legacy_user'@'localhost' - 立即启用：
SET DEFAULT ROLE 'legacy_ro' TO 'legacy_user'@'localhost' - 确认生效后，再逐步
REVOKE原来的直授权限（如REVOKE SELECT ON prod_db.* FROM 'legacy_user'@'localhost'）
注意：REVOKE 动作本身不会影响角色权限，但必须等角色已激活且验证无误后再执行，否则权限真空。
角色权限在 Docker 初始化脚本中怎么写才可靠
镜像启动时跑初始化 SQL，容易因执行顺序问题导致角色未创建就授给用户。务必保证语句顺序和事务边界清晰：
CREATE ROLE IF NOT EXISTS 'web_app'; GRANT SELECT, INSERT, UPDATE ON `myapp`.* TO 'web_app'; CREATE USER IF NOT EXISTS 'web_user'@'%' IDENTIFIED BY 'pwd'; GRANT 'web_app' TO 'web_user'@'%'; SET DEFAULT ROLE 'web_app' TO 'web_user'@'%';
关键点：所有语句必须在同一文件中、按序排列；IF NOT EXISTS 防止重复创建报错；不要在脚本里加 FLUSH PRIVILEGES —— MySQL 8.0+ 的 GRANT 和 CREATE ROLE 自动刷新元数据，加了反而可能干扰初始化流程。
真正容易被忽略的是 host 段一致性与 SET DEFAULT ROLE 的强制性——这两个点一旦出错，用户连上去查 SELECT USER(), CURRENT_ROLE() 都看不到有效角色，权限形同虚设。
