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；开太少又漏关键行为。没有一劳永逸的配置，得根据业务流量和审计目标反复调。
