mysql日志权限控制核心是分离“写入”与“读取”：日志开启不依赖权限，但查表需select权限；建议用审计账号限定访问，禁用FILE权限防文件泄露，并用performance_schema替代general_log实现细粒度、低开销审计。
MySQL 的 general_log 和 slow_query_log 如何配合权限控制
开启日志本身不依赖用户权限，但读取日志内容（尤其是写入到表时）直接受 SELECT 权限限制。如果日志写入到 mysql.general_log 或 mysql.slow_log 表，普通用户默认无权查询这些表——哪怕日志已记录，SELECT * FROM mysql.general_log 会直接报错 Error 1142 (42000): SELECT command denied。
实操建议：
- 仅对审计专用账号授予
SELECT权限：GRANT SELECT ON mysql.general_log TO 'auditor'@'%'; - 避免使用
FILE权限启用日志写入文件（如general_log_file = /var/lib/mysql/general.log），否则任意有FILE权限的用户都可能通过LOAD_FILE()读取日志文件 - 若必须写入文件，确保 MySQL 进程用户（如
mysqld）对日志路径有写权限，且系统级权限严格限制该目录的读取范围
如何用权限隔离日志查看范围
MySQL 不支持按用户、数据库或 IP 对日志内容做行级过滤。日志是全局行为，但可通过权限间接控制“谁能看、看多少”。
关键点：
-
PROCESS权限决定能否执行SHOW PROCEsslIST，它能实时看到当前连接和正在执行的语句，效果接近轻量级访问日志，但不持久 - 授予
SELECT权限到特定库的视图（如基于performance_schema.events_statements_history构建），比直接开放mysql.general_log更安全 - 禁用
super_priv的账号无法修改general_log或slow_query_log系统变量，因此不能随意开关日志——这是权限配合的第一道防线
slow_query_log 的 long_query_time 与权限无关但影响日志体积
long_query_time 是纯性能阈值参数，不涉及权限校验，但它直接影响慢日志的条目数量和磁盘占用。权限再严，如果设成 0.1 秒，所有查询都会进慢日志，等于变相开启全量日志。
注意事项：
- 该参数可动态设置，但只有拥有
SYSTEM_VARIABLES_ADMIN或SUPER权限的用户才能执行SET GLOBAL long_query_time = 1.0; - 注意精度：MySQL 5.7+ 支持微秒级（如
0.05），但低版本只识别整数秒，设0.1实际等效于0 - 日志中记录的
Query_time值受锁等待、IO 等影响，不一定反映应用层感知的延迟，别单靠它判断接口瓶颈
用 performance_schema 替代 general_log 做细粒度审计
general_log 是粗粒度、高开销的全量记录；而 performance_schema 可按账号、主机、阶段事件开启采集，且无需 FILE 或 SUPER 权限（只需 SELECT 对应表）。
典型配置步骤：
- 确认已启用：
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema';返回ON - 为指定用户开启语句收集：
UPDATE performance_schema.setup_actors SET ENABLED = 'YES' WHERE HOST = '192.168.1.%' AND USER = 'app_user'; - 启用语句事件记录：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME = 'statement/sql/select'; - 查询结果：
SELECT USER, HOST, SQL_TEXT FROM performance_schema.events_statements_history WHERE SQL_TEXT LIKE '%order%';
真正难的是平衡：开太多 instruments 会明显拖慢 QPS；开太少又漏关键行为。没有一劳永逸的配置，得根据业务流量和审计目标反复调。