mysql无原生用户组机制，权限基于用户名@主机精确匹配；所谓“多组权限冲突”实为账户匹配优先级、跨粒度权限不一致或未刷新权限所致，应通过select user(), current_user()和show grants定位实际生效账户及权限。
MySQL本身不支持“用户组”概念，也没有原生的用户组权限管理机制（如Linux的group或Active Directory中的组策略）。所谓“用户组中用户组”的权限交集或差集问题，在标准MySQL中并不存在——它不是通过组来继承或叠加权限的，而是严格基于 用户名@主机 这一唯一标识进行权限匹配和合并。
为什么会出现“多组权限冲突”的错觉？
实际中所谓“多组权限交集/差集导致读取报错”，通常源于以下几种真实场景：
-
同一用户存在多个Host记录：例如
'app'@'192.168.1.10'和'app'@'%'同时存在，MySQL会按匹配优先级（最具体到最宽泛）选择一个账户认证，而CURRENT_USER()显示的是被选中的那个。若后者权限更小（比如只给了SELECT），即使前者有DELETE也无效。 -
跨粒度权限不一致：比如全局授予了
DELETE（ON *.*），但表级只给了SELECT, INSERT（ON db.t1）。MySQL在执行DELETE FROM t1时，会检查该操作所需的全部权限——包括SELECT（用于定位行，尤其涉及WHERE或子查询时）。此时若表级没给SELECT，就会报“command denied”，哪怕全局有DELETE。 -
权限未刷新或缓存未同步：直接修改
mysql.user等系统表后未执行FLUSH PRIVILEGES，或使用GRANT后因异常中断导致权限未持久化，造成磁盘与内存权限状态不一致。
如何排查和解决这类“权限交集失效”问题
关键不是计算交集，而是确认当前连接实际匹配哪个账户、该账户拥有哪些生效权限：
- 登录后立即执行：
SELECT USER(), CURRENT_USER();—— 对比两者，确认你“以为自己是哪个用户”，和MySQL“认为你是谁”是否一致。 - 查所有同名用户：
SELECT Host, User FROM mysql.user WHERE User = 'your_user';，重点看Host是否覆盖你的连接来源（如用127.0.0.1连，'user'@'localhost'不生效）。 - 查确切权限：
SHOW GRANTS FOR CURRENT_USER();或SHOW GRANTS FOR 'user'@'host';，不要依赖记忆或旧脚本。 - 若发现权限缺失，统一在同一粒度层级补全所需权限。例如表级操作出错，就补表级
SELECT：GRANT SELECT ON `db`.`table` TO 'user'@'host';
替代方案：模拟“用户组”行为
虽然MySQL无原生组，但可通过以下方式实现类似效果：
-
角色（Role，MySQL 8.0+）：创建角色并授予权限，再把角色赋予多个用户。
CREATE ROLE 'app_reader'; GRANT SELECT ON mydb.* TO 'app_reader'; GRANT 'app_reader' TO 'u1'@'%', 'u2'@'%';。权限变更只需改角色，自动同步到所有成员。 -
脚本批量授权：对一批用户执行相同
GRANT语句，确保权限定义一致，避免手动遗漏。 - 应用层统一账号：让应用始终使用单一高权限账号连接，权限控制交给应用逻辑（需谨慎评估安全边界）。
本质上，这不是权限交集计算问题，而是账户匹配与权限粒度对齐问题。抓住 CURRENT_USER() 和 SHOW GRANTS 这两个关键命令，就能快速定位真实瓶颈。
