mysql权限策略本质是grant/revoke语句的组合，无独立策略配置；通过角色模拟策略分组，行级控制需依赖视图或应用层；权限修改对当前会话不生效，flush privileges仅用于直接改系统表。
MySQL 权限策略本质是 GRANT/REVOKE 语句的组合，不是独立配置文件
MySQL 没有像 PostgreSQL 那样的“策略（Policy）”概念，也没有基于角色的细粒度行级策略引擎（如 RLS）。所谓“权限策略”，实际就是对 GRANT 和 REVOKE 的合理编排，配合用户、角色、数据库对象三级权限控制。误以为存在类似 my.cnf 中可声明式定义的“策略配置”，会导致权限管理混乱。
用角色（ROLE）模拟策略分组，避免重复授权
从 MySQL 8.0 开始支持角色，这是最接近“策略模板”的机制。比如定义一个 app_reader 角色，统一授予只读权限，再把该角色分配给多个应用用户：
CREATE ROLE app_reader; GRANT SELECT ON `sales`.* TO app_reader; GRANT app_reader TO 'user_a'@'%', 'user_b'@'%';
后续只需调整 app_reader 的权限，所有成员自动继承。注意：SET DEFAULT ROLE 必须显式执行，否则新连接不会激活角色：
SET DEFAULT ROLE app_reader TO 'user_a'@'%';- 角色不能跨实例复用，备份恢复后需重新创建
- 角色本身不拥有密码，也不可直接登录
WHERE 条件无法用于 GRANT —— 行级控制必须靠视图或应用层
常见误区：试图用 GRANT SELECT ON sales.orders WHERE status = 'active' 实现数据行过滤。MySQL 不支持这种语法，GRANT 语句中不允许出现 WHERE。
可行替代方案：
- 为敏感字段或行集创建视图（
CREATE VIEW active_orders AS SELECT * FROM orders WHERE status = 'active';），再对视图授权 - 在应用连接时使用固定
SQL SECURITY DEFINER存储过程封装查询逻辑 - 依赖中间件（如 ProxySQL）或 ORM 层做查询重写（非 MySQL 原生能力）
权限生效延迟与 FLUSH PRIVILEGES 的真实作用
修改权限后不生效？先确认是否遗漏关键步骤：
- 用
GRANT或REVOKE修改权限后，**当前会话不立即生效**，新连接才使用更新后的权限 -
FLUSH PRIVILEGES仅在**直接修改mysql.user等系统表**后才需要；通过GRANT操作无需执行它 - 如果用户已存在活跃连接，其权限缓存会持续到连接断开，强制断开可用：
KILL [connection_id]; - 检查是否因 host 匹配失败导致权限未命中（如
'user'@'192.168.%'不匹配'user'@'192.168.10.5'）
权限模型里最容易被忽略的是 host 字段的精确匹配和大小写敏感性——它不是通配符模糊搜索，而是严格字符串比对。
