如何用 mysql.sys
表配合权限控制实现基础审计
MySQL 自带的
sys库（尤其是
mysql.sys下的视图）不是独立服务，但能快速暴露用户行为痕迹，前提是对应账号有足够权限读取性能模式数据。默认普通用户看不到
performance_schema里的表，更别说
sys视图。
实操建议：
给审计账号授予SELECT权限到
performance_schema.*和
sys.*，不要用
ALL PRIVILEGES—— 这会绕过最小权限原则，也容易被误删配置
sys.session和
sys.processlist可实时查当前连接与 SQL 摘要，但不记录历史；真要留痕得靠
performance_schema.events_statements_history_long，它默认只存 10000 条，且重启清空 若发现
SELECT * FROM sys.session返回空，先检查是否启用了
performance_schema（
SHOW VARIABLES LIKE 'performance_schema'必须为
ON）
开启 general_log
的真实代价与替代方案
很多人一上来就开
general_log = ON，以为这就是审计。结果不到半天磁盘爆满，或主库响应变慢——因为每条语句（包括心跳、健康检查）都会写入日志，IO 压力陡增。
实操建议：
仅在排查阶段临时启用：SET GLOBAL general_log = ON，并指定文件路径（
SET GLOBAL general_log_file = '/var/log/mysql/general.log'），用完立刻关 生产环境更推荐用
audit_log插件（MySQL Enterprise Edition）或 Percona Server 的
audit_log（开源版），它们支持按用户、命令类型过滤，还能输出 JSON 格式便于接入 SIEM 如果只能用社区版又必须留痕，可考虑触发器 + 日志表组合，但注意：DML 触发器无法捕获
DROP TABLE或
GRANT等 DDL/DCL 操作
GRANT
时漏掉 WITH GRANT OPTION
导致审计链断裂
审计不是只看“谁执行了什么”，更要确认“谁授权了谁”。如果给中间管理账号（如 DBA 助理）授了
SELECT，却没加
WITH GRANT OPTION，那他后续再转授他人时会失败；但如果加了，又没人监控他转授了哪些权限，审计日志里就只剩结果，没有授权路径。
实操建议：
所有含WITH GRANT OPTION的
GRANT操作，必须同步记录到外部 CMDB 或审批系统，不能只依赖 MySQL 自身的
information_schema.role_table_grants定期用
SELECT * FROM mysql.proxies_priv（需
SELECT权限）核对代理权限扩散情况，这个表不会出现在
SHOW GRANTS输出中，容易被忽略 避免使用
GRANT ALL ON *.*，哪怕只是临时测试——它隐式包含
GRANT OPTION，且可能赋予
FILE、
SHUTDOWN等高危权限
日志轮转与权限分离的实际落地难点
审计日志要长期保存，就得轮转；但轮转脚本若用 root 运行，等于把日志访问权交给了运维账号；若用 mysql 用户运行，又可能因权限不足无法压缩或归档旧文件。
实操建议：
用logrotate配合
create 640 mysql mysql，确保新日志文件属主是
mysql，但组可读（供审计账号通过组权限访问） 审计账号不应有
FILE权限，否则可通过
SELECT ... INTO OUTFILE绕过日志机制直接导出敏感数据 如果用
audit_log插件，注意其日志文件由 mysqld 进程自身写入，
logrotate的
copytruncate模式可能造成少量丢失，建议用
prerotate调用
FLUSH LOGS再轮转
真正难的不是配参数，而是让日志内容和权限边界对齐：一条
DROP DATABASE记录背后，得能立刻定位到是谁授权了这个账号、该账号上次密码修改时间、是否开启了双因素认证——这些信息散落在不同系统里，MySQL 本身不负责串联。
