MySQL 8.0中ROLE是实际可用的权限模板，而非可选语法糖，它是微服务权限批量管控的基础设施；通过创建角色、授予权限、绑定用户并设默认角色四步实现最小特权与高效复用。
MySQL 8.0 中没有“权限模板”这个内置概念，但 ROLE 就是实际可用的权限模板——它不是锦上添花的语法糖，而是微服务权限批量管控的基础设施。直接给每个服务用户授一堆 GRANT，等于把权限逻辑写死在脚本里，改一个权限就得遍历所有用户。
为什么必须用 ROLE 而不是直接 GRANT 用户
微服务数量一多（比如 12 个服务），每个服务又分读/写/管理角色，手动维护 GRANT SELECT ON orders TO 'svc_payment'@'10.100.30.%' 这类语句极易出错：漏授权、错主机段、权限冗余、回收不及时。而 ROLE 把权限打包命名后，后续只需 GRANT 'order_reader' TO 'svc_payment'@'10.100.30.%' 一行搞定，变更也只改角色本身。
- 角色可复用：多个服务共用
'product_reader'，新增服务时不用重写权限 SQL - 权限回收可控：先
REVOKE 'product_reader' FROM 'svc_search'@'10.100.30.%'，再DROP ROLE 'product_reader'，不会误删其他用户权限 - 避免 ALL PRIVILEGES：角色天然限制粒度，没法直接授予
ALL PRIVILEGES ON *.*，从机制上防住高危配置
创建 ROLE 模板的实操要点
模板不是随便起个名就完事。要贴业务真实 SQL 流量，不能按“订单服务”这种功能名建角色，而要按它实际访问的表和操作类型来定义：
- 先开
general_log：在预发环境执行典型链路（如下单、查库存），然后跑SELECT DISTINCT SUBSTRING_INDEX(SUBSTRING_INDEX(argument, ' ', 3), ' ', -1) FROM mysql.general_log WHERE argument LIKE 'SELECT %' AND argument NOT LIKE '%information_schema%';提取真实表名 - 建角色时限定库+表+操作：比如
CREATE ROLE 'inventory_ro'; GRANT SELECT ON mydb.inventory TO 'inventory_ro';，绝不写mydb.*或*.* - 主机段必须精确：用
'svc_inventory'@'10.100.30.%'，禁用'%'；若服务部署在 Kubernetes，可用网段（如10.244.0.%）或 Service CIDR - 必须设默认角色：
SET DEFAULT ROLE 'inventory_ro' TO 'svc_inventory'@'10.100.30.%';，否则用户登录后权限不生效
查权限和验证是否生效的常见盲区
SHOW GRANTS FOR 'svc_inventory'@'10.100.30.%' 看不到角色权限——这是 MySQL 的设计行为，不是 bug。想确认权限是否真生效，得用下面两种方式之一：
- 查角色绑定权限：
SHOW GRANTS FOR 'svc_inventory'@'10.100.30.%' USING 'inventory_ro'; - 登录后执行：
CURRENT_ROLE();和SELECT USER(), CURRENT_USER();确认连接身份和激活角色 - 权限变更后旧连接不刷新：已连上的会话仍用旧权限，新权限只对新连接或显式执行
SET ROLE 'inventory_ro';生效 - 跨库权限写法易错：不能写
GRANT SELECT ON *.products，必须写全GRANT SELECT ON mydb.products
真正难的不是建几个 ROLE，而是让每个服务的 SQL 流量被持续观测、角色权限随表结构演进同步更新、以及开发申请权限时能准确描述“我要查哪张表的哪些字段”。这些环节一旦松动，ROLE 就会退化成另一个形式主义空壳。
