FILE权限不能直接用于读取日志文件，它仅控制LOAD_FILE()等语句访问本地文件系统，不赋予读取general_log_file等物理日志文件的权限；日志文件属主为mysql用户，读取需系统级权限或通过log_output='TABLE'配合SELECT权限实现。
FILE权限不能直接用于读取日志文件
MySQL 的 FILE 权限不是为“读取日志”设计的，而是控制 LOAD_FILE()、SELECT ... INTO OUTFILE 和 LOAD DATA INFILE 这类语句能否访问服务器本地文件系统。它**不赋予用户读取 general_log_file 或 slow_query_log_file 物理文件的权限**——这些日志文件由 mysqld 进程以自身系统用户（如 mysql）身份写入，权限归属操作系统层面。
常见误解是：开了 FILE 权限就能用 SELECT LOAD_FILE('/var/log/mysql/general.log') 拿到日志内容。但实际会失败，原因包括：
-
LOAD_FILE()要求文件必须由 mysqld 进程可读，且路径需在secure_file_priv配置值范围内（默认常为空或/var/lib/mysql-files/） - 日志文件通常属主为
mysql:mysql，权限为640，普通数据库用户无法绕过 OS 层直接读取 - 开启
general_log = ON并设general_log_file = /path/to/file后，任何有FILE权限的用户都可能通过LOAD_FILE()读取该文件 —— 这本身就是严重的审计风险
真正需要的是 REPLICATION CLIENT + 系统级文件访问控制
日志收集系统（比如 Prometheus + mysqld_exporter、Logstash、自研 agent）要获取 binlog 或 slow log 内容，核心依赖不是数据库账号权限，而是：
- 对
mysql.binlog的元信息访问：需REPLICATION CLIENT权限（全局权限，只能用*.*授予） - 对物理日志文件（如
/var/log/mysql/slow.log）的读取：靠系统用户（如logstash）加入mysql用户组，并确保日志目录有g+r权限 - 若使用
mysqlbinlog命令远程拉取 binlog：需REPLICATION SLAVE权限，且 MySQL 必须启用binlog_format = ROW或MIXED
例如，给日志收集用户 logreader 授权：
CREATE USER 'logreader'@'localhost' IDENTIFIED BY 'strong-pass'; GRANT REPLICATION CLIENT ON *.* TO 'logreader'@'localhost'; FLUSH PRIVILEGES;
这能让它执行 SHOW BINARY LOGS、SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS 等诊断命令，但**仍无法直接读取磁盘上的 slow_query_log_file 文件**。
如果必须让 MySQL 自己输出日志内容到 SQL 查询结果中
唯一安全可行的方式是把日志写入表（而非文件），再用标准 SELECT 查询：
- 启用表格式日志：
SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE'; - 此时日志会写入
mysql.general_log表，授予最小权限即可：GRANT SELECT ON mysql.general_log TO 'logreader'@'localhost'; - 注意：
mysql.general_log是 CSV 引擎表，无索引，大流量下SELECT *会锁表并拖慢写入；建议只查最近 N 行或按event_time过滤 - 同理，慢查询日志也可用
log_output = 'TABLE'写入mysql.slow_log，但需先确认slow_query_log已开启
不要混用：log_output = 'FILE,TABLE' 会导致双写，且 FILE 部分依然不受数据库权限控制。
配置 FILE 权限本身的风险与限制
如果你因其他需求（比如 ETL 导入导出）确实要开 FILE 权限，必须同步做三件事：
- 检查并收紧
secure_file_priv：在my.cnf的[mysqld]段显式设置，如secure_file_priv = /var/lib/mysql-files/；设为空值（''）等于完全放开，极度危险 - 禁止日志写入
secure_file_priv允许的路径：比如不要把general_log_file设成/var/lib/mysql-files/general.log，否则任意有FILE权限的用户都能读取 - 避免给非 DBA 用户授
FILE：它是高危权限，与SHUTDOWN、SUPER并列；MySQL 8.0+ 中甚至被标记为 “deprecated for removal in future”
最常被忽略的一点：即使你严格限制了 secure_file_priv，只要 MySQL 进程能读某个日志文件（比如因为 log_error 指向了 /tmp/mysql.err），而该路径又恰好落在 secure_file_priv 范围内，攻击者就可能用 LOAD_FILE() 泄露错误堆栈或凭证 —— 所以日志路径和 secure_file_priv 必须物理隔离。
