mysql 8.0 微服务最小特权模型需基于真实sql流量精确授权：先开general_log采集表与操作类型，再用角色封装表级权限，限定主机段（如10.100.30.%），禁用%、all privileges等高危配置，并显式设置default role。
MySQL 8.0 中为微服务设计最小特权模型，核心是「每个服务只拥有它 SQL 实际执行所必需的那几条权限」——不是按功能命名（如 order_service），而是按它真实访问的表、字段、主机段和操作类型来精确建模。
先确认每个服务真实访问哪些表和操作
别猜，直接看流量。在测试或预发环境开启 general_log，跑一轮典型链路（下单、查订单、更新库存等），然后提取真实涉及的表和语句类型：
- 开日志：
SET GLOBAL general_log = ON;，日志会写入mysql.general_log - 查表名：
SELECT DISTINCT SUBSTRING_INDEX(SUBSTRING_INDEX(argument, ' ', 3), ' ', -1) FROM mysql.general_log WHERE argument LIKE 'SELECT %' OR argument LIKE 'INSERT %' OR argument LIKE 'UPDATE %'; - 过滤掉
information_schema、performance_schema等系统库结果，只保留业务库下的表（如orders、inventory）
常见错误是直接给 GRANT SELECT ON mydb.* TO 'svc_order'@'%' —— 这等于把日志表、配置表、审计表全放开，且 '%' 允许任意 IP 连接，认证流量裸奔。
用角色封装权限组合，禁止直接授予权限
MySQL 8.0 的角色不是可选项，是微服务权限批量管控的基础设施。多个服务共用一类权限（比如都只读订单相关表），靠角色才能避免重复授权和漏回收。
- 建角色：
CREATE ROLE 'order_reader', 'order_writer'; - 授表级权限（不带列）：
GRANT SELECT ON mydb.orders TO 'order_reader'; GRANT SELECT, INSERT, UPDATE ON mydb.orders TO 'order_writer'; - 创建服务用户并绑定：
CREATE USER 'svc_order'@'10.100.30.%' IDENTIFIED BY 'xxx'; GRANT 'order_reader' TO 'svc_order'@'10.100.30.%'; - 必须激活默认角色：
SET DEFAULT ROLE 'order_reader' TO 'svc_order'@'10.100.30.%';（否则登录后权限不生效）
注意：SHOW GRANTS FOR 'svc_order'@'10.100.30.%' 不显示角色权限，要查 SHOW GRANTS FOR 'svc_order'@'10.100.30.%' USING 'order_reader'; 或登录后执行 CURRENT_ROLE()。
主机段必须具体，禁用高危配置项
微服务通常部署在固定网段（如 K8s Pod CIDR），'%' 和 'localhost' 都不可接受。
- 推荐写法：
'svc_order'@'10.100.30.%'或 CIDR 格式（MySQL 8.0+ 支持）：'svc_order'@'10.100.0.0/255.255.0.0' - 绝对禁用：
GRANT ALL PRIVILEGES ON *.*、GRANT ... WITH GRANT OPTION、root远程访问、匿名用户、FLUSH PRIVILEGES（8.0+ 授权后无需执行） - 敏感字段（如
password_hash、deleted_at）不能靠列权限兜底——MySQL 列级 DML 权限对UPDATE ... SET无效，必须由应用逻辑拦截
运维脚本需临时提权时，用动态授权 + 显式回收模式，而不是给长期账号 BACKUP_ADMIN 或 PROCESS 权限。
元数据权限要单独控制，别让 SELECT 权限“顺手”看到结构
SELECT 权限不包含任何元数据访问能力。ORM 自动探测表结构、SHOW CREATE TABLE、甚至 DESCRIBE orders，都需要额外权限。
- 若服务真需要查列信息：
GRANT SELECT ON information_schema.columns TO 'svc_order'@'10.100.30.%' WHERE table_schema = 'mydb';（MySQL 8.0+ 支持行级过滤，但更稳妥的是应用层隔离） - 禁用
GRANT SELECT ON *.*—— 它隐式授予information_schema和performance_schema的读权限，暴露大量内部状态 - 不要给
SHOW DATABASES，除非服务明确需要跨库发现机制
最易被忽略的一点：角色权限在用户登录后不会自动启用，SET DEFAULT ROLE 必须显式执行，且该语句本身需要 ROLE_ADMIN 权限——这个权限应仅授予 DBA 账号，不能下放给服务账号。
