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 字段的精确匹配和大小写敏感性——它不是通配符模糊搜索，而是严格字符串比对。
