MySQL无原生组权限，5.7及以前仅能批量GRANT；8.0起通过CREATE ROLE+GRANT TO ROLE+SET ROLE模拟，但需手动启用且非自动继承，本质是权限容器而非OS级group。
MySQL 本身没有原生的“组权限”（group-level privileges）概念，GRANT 和 REVOKE 操作始终面向具体用户（'user'@'host'），所谓“组权限”是通过人工约定或外部工具模拟出来的逻辑，不是服务端内置机制。
MySQL 里为什么没有真正的 GROUP 权限？
MySQL 的权限系统基于 mysql.user、mysql.db、mysql.tables_priv 等系统表，所有权限记录都绑定到 User + Host 组合。没有 mysql.role 表（5.7 及以前），也没有角色（Role）抽象层——直到 MySQL 8.0 才引入 CREATE ROLE 和 GRANT ... TO role_name，但这也只是“类组”能力，不是传统意义上的 Unix-style group。
- 5.7 及更早版本：只能靠重复执行
GRANT或脚本批量赋权 - MySQL 8.0+：可用
ROLE模拟组，但需显式启用并手动分配给用户 - 权限继承不自动发生；
role不等于OS group，也不影响连接认证
MySQL 8.0 中用 ROLE 模拟“组权限”的实操步骤
这是目前最接近“组权限”的官方方案，但要注意它只是权限容器，不带生命周期或成员管理功能。
- 创建角色：
CREATE ROLE 'dev_team';
- 给角色授予权限：
GRANT SELECT, INSERT ON myapp.* TO 'dev_team';
- 把角色分配给用户：
GRANT 'dev_team' TO 'alice'@'192.168.1.%';
- 用户登录后需激活角色（默认不自动启用）：
SET ROLE 'dev_team';
或在账号创建时设为默认：ALTER USER 'alice'@'192.168.1.%' DEFAULT ROLE 'dev_team';
注意：SHOW GRANTS FOR 'dev_team'; 查角色权限，SHOW GRANTS FOR 'alice'@'192.168.1.%'; 查用户直授 + 角色继承权限。
常见误操作与权限失效原因
很多“权限不生效”问题其实和“组”无关，而是权限作用域或激活机制没理清：
-
GRANT ... ON *.*和GRANT ... ON db.*权限层级不同，后者无法访问其他库 - 忘记
FLUSH PRIVILEGES;？不需要——GRANT会自动刷新内存权限缓存 - 用户从
'user'@'%'连接，但权限只给了'user'@'localhost'：host 匹配失败 - MySQL 8.0 启用
roles后，用户登录不执行SET ROLE或未设DEFAULT ROLE，角色权限不可见 - 使用
mysqldump或客户端工具时，若连接参数未指定--set-gtid-purged=OFF等，可能因权限不足静默失败，而非报错
替代方案：用脚本或配置中心统一管理“类组权限”
如果还在用 MySQL 5.7 或不想依赖 8.0 的 role 特性，常见做法是把权限语句写成模板，用 shell/Python 批量生成并执行：
- 维护一个
dev_users.txt文件，每行一个user@host - 用 Python 读取并拼出批量
GRANT语句：for user_host in open('dev_users.txt'): print(f"GRANT SELECT, INSERT ON myapp.* TO {user_host.strip()};") - 导出后用
mysql -u root -p 执行 - 生产环境建议加
SELECT校验：SELECT User, Host, Select_priv, Insert_priv FROM mysql.db WHERE Db='myapp';
这类方案灵活，但缺乏审计追踪；上线前务必在测试库验证权限是否按预期加载。
真正容易被忽略的是 host 匹配规则和 role 的默认激活行为——哪怕建了 role、也 GRANT 了，用户连上去没 SET ROLE 或没设 DEFAULT ROLE，权限就等于没给。
