MySQL不支持“数据仓库导出权限”，需为用户授予SELECT和LOCK TABLES等最小必要权限；FILE权限为全局静态权限，风险高且受secure_file_priv限制，mysqldump导出无需FILE权限。
MySQL 本身不支持“给数据仓库分配导出权限”这种说法——它没有“数据仓库”这个内置角色或对象类型，也没有 FILE 权限的批量授予机制。真正需要的是：为特定用户授予 SELECT（读取数据）和 FILE（写入服务器本地文件）权限，并确保其作用域、上下文和安全限制被正确认知。
为什么不能直接用 GRANT FILE ON *.* 给普通用户？
FILE 是全局静态权限（global privilege），只能授予 ON *.*，且仅对拥有 GRANT OPTION 的高权限账号（如 root）开放；普通用户即使被授予，MySQL 启动时若未启用 --secure-file-priv 或该参数设为非空目录，SELECT ... INTO OUTFILE 仍会报错 ERROR 1290 (HY000)。
-
FILE不是数据库级或表级权限，无法限定到某个库或某张表 - 授予
FILE意味着该用户可在 MySQL 服务所在机器的任意可写路径生成文件（含 /etc/passwd、/root/.bash_history 等敏感位置，如果权限配置不当） - MySQL 8.0+ 默认启用
secure-file-priv，值通常为/var/lib/mysql-files/或NULL；设为NULL时，INTO OUTFILE直接禁用
mysqldump 导出不需要 FILE 权限，但需要哪些权限？
绝大多数批量导出场景实际走的是客户端工具 mysqldump，它在客户端执行，不依赖 MySQL 服务端写文件，因此 完全不需要 FILE 权限。真正需要的是：
-
SELECT：读取所有目标表的数据（必须） -
LOCK TABLES：保证导出一致性（加锁，推荐开启；若用--single-transaction可规避，但要求引擎为 InnoDB） -
SHOW VIEW：若导出包含视图 -
TRIGGER：若导出包含触发器 -
EVENT：若导出事件调度器内容（需--events参数）
例如，给用户 dw_exporter@'10.10.20.%' 授予导出 sales_dw 库全部表的最小权限：
GRANT SELECT, LOCK TABLES ON `sales_dw`.* TO 'dw_exporter'@'10.10.20.%';
执行后务必运行 FLUSH PRIVILEGES;（尤其在非 root 账户下修改权限表后）。
真要用 SELECT ... INTO OUTFILE 批量导出？先检查三件事
若因性能或管道需求必须用服务端导出（比如拼接大宽表后直出 CSV），请确认：
- MySQL 配置中
secure-file-priv值不是NULL（查法：SHOW VARIABLES LIKE 'secure_file_priv';） - 目标路径（如
/var/lib/mysql-files/exports/）在操作系统层面已存在、属主为mysql用户、有写权限 - 用户已获
FILE权限：GRANT FILE ON *.* TO 'dw_exporter'@'10.10.20.%';（注意：必须由 root 或带GRANT OPTION的账号执行）
然后才能执行类似语句：
SELECT * FROM sales_dw.fact_orders INTO OUTFILE '/var/lib/mysql-files/exports/fact_orders.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n';
批量授权脚本怎么写才安全？别漏掉 host 和 FLUSH
批量操作本质是生成并执行多条 GRANT，常见错误包括：
- 把
'user'@'%'写成'user'@'localhost'，导致远程应用连不上 - 忘记对每个
GRANT后加FLUSH PRIVILEGES;（某些版本下延迟生效） - 用
CREATE USER+GRANT分开执行，但没处理用户已存在的情况（会报错） - CSV 文件里字段含逗号或换行，导致 shell
while read解析错位
更稳妥的做法是手写 SQL 文件（如 grant_dw_perms.sql），内容示例：
CREATE USER IF NOT EXISTS 'dw_exporter'@'10.10.20.%' IDENTIFIED BY 'StrongP@ss2026'; GRANT SELECT, LOCK TABLES ON `sales_dw`.* TO 'dw_exporter'@'10.10.20.%'; GRANT SELECT, LOCK TABLES ON `dim_customer`.* TO 'dw_exporter'@'10.10.20.%'; FLUSH PRIVILEGES;
再用 mysql -uroot -p < grant_dw_perms.sql 执行。
真正容易被忽略的点是：FILE 权限一旦授予，就等于给了该用户绕过客户端、直接在数据库服务器上写任意文件的能力——哪怕只允许导出一张表，攻击者也能用 SELECT ... INTO OUTFILE '/var/lib/mysql-files/.ssh/authorized_keys' ... 植入 SSH 后门。所以除非强需求，否则优先走 mysqldump + 客户端存储路径。
