MySQL批量授权只能通过执行GRANT语句实现，无授权文件机制；需用具备GRANT OPTION权限的账号（如root）执行脚本，建议每条GRANT后加FLUSH PRIVILEGES；推荐手写SQL文件（如grants.sql）生成可执行语句。
MySQL 批量授权必须用 SQL 语句，没有“授权文件”机制
MySQL 本身不支持像 my.cnf 那样的配置文件直接定义用户权限。所谓“授权文件”是常见误解——实际批量授权只能靠执行一批 GRANT 语句，通常通过 SQL 脚本实现。
常见错误现象：ERROR 1045 (28000): Access denied for user 或 ERROR 1142 (42000): GRANT command denied，多因执行脚本的账号没被赋予 GRANT OPTION 权限。
- 必须用有
GRANT OPTION的账号（如root）执行脚本 - 脚本中每条
GRANT后建议加FLUSH PRIVILEGES;（仅在直接操作mysql.user表时强制需要；用GRANT语句通常自动刷新，但批量场景下显式调用更稳妥） - 避免在脚本里写明文密码；若需创建用户，用
CREATE USER ... IDENTIFIED WITH caching_sha2_password BY 'xxx';（MySQL 8.0+ 默认）
生成 GRANT 语句的三种实用方式
核心思路：把权限规则转成可执行的 SQL 字符串。不是靠外部文件“注入”，而是生成、校验、再执行。
-
手写 SQL 文件：适合固定权限结构，例如
grants.sql包含：GRANT SELECT, INSERT ON `app_db`.* TO 'app_user'@'192.168.1.%'; GRANT USAGE ON *.* TO 'monitor_user'@'localhost' REQUIRE SSL;
然后用mysql -u root -p 执行 -
用 SELECT 拼接生成：从已有用户或模板表动态构造，例如：
SELECT CONCAT('GRANT SELECT ON `', table_schema, '`.* TO ''report_user''@''%'';') FROM information_schema.schemata WHERE schema_name NOT IN ('mysql','information_schema','performance_schema');复制结果，粘贴执行 -
Shell + MySQL 联合脚本：比如按 CSV 列表批量建用户：
while IFS=, read -r db user host perms; do mysql -Nse "GRANT $perms ON \`${db}\`.* TO '$user'@'$host';" done
MySQL 8.0+ 注意 role 和 partial_revokes 的干扰
如果目标实例启用了角色（roles）或设置了 PARTIAL REVOKES，单纯跑 GRANT 可能不生效或报错 ERROR 3790 (HY000)。
- 先查是否启用：执行
SELECT @@global.partial_revokes;，返回1表示开启 - 若有 role，优先用
CREATE ROLE+GRANT ... TO role_name;+GRANT role_name TO user;，比直接授给用户更可控 - 遇到
ERROR 3790时，要么先REVOKE冲突权限，要么临时关掉partial_revokes（需重启，生产慎用）
权限未立即生效？检查这三点
执行完批量 GRANT 后仍连不上或报权限错，大概率不是语法问题，而是环境细节没对齐：
- 客户端连接时用的
user@host必须和GRANT中定义的完全一致（包括域名解析结果：比如'user'@'%'不等价于'user'@'localhost'） - MySQL 8.0 默认认证插件是
caching_sha2_password，老客户端可能不兼容，需显式指定：ALTER USER 'u'@'h' IDENTIFIED WITH mysql_native_password BY 'pw'; - 防火墙或代理（如 ProxySQL、MaxScale）可能缓存了旧权限元数据，重启或清空其权限缓存
真正麻烦的从来不是写多少条 GRANT，而是 host 匹配逻辑、认证插件切换、以及权限叠加时的隐式覆盖——这些点不提前验证，批量操作后反而更难排查。
