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，权限就等于没给。
