审计日志抓不到配置文件读取，因为my.cnf由操作系统在MySQL启动或重载时通过fopen()等系统调用读取，属于进程级行为，不在MySQL服务器审计范围内；需用auditd、inotifywait等系统级工具监控。
审计日志本身不记录对数据库配置文件（如 my.cnf、my.ini）的读取行为——因为这类文件由操作系统在 MySQL 启动或重载时读取，不属于数据库运行时的 SQL 或连接操作，MySQL 审计插件（如 audit_log、server_audit）无法捕获该过程。
为什么审计日志抓不到配置文件读取
MySQL 审计日志只监控数据库服务内部事件，例如：
- 用户连接/断开（CONNECT/DISCONNECT）
- SQL 执行（SELECT/INSERT/ALTER 等）
- 权限变更（GRANT/REVOKE）
- 存储过程调用、函数执行
而 my.cnf 是 mysqld 进程启动时由操作系统内核或 C 标准库（如 fopen()）打开读取的，属于进程级系统行为，不在 MySQL 服务器的审计上下文中。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
真正能追踪配置文件访问的方法
要监控谁、何时、以何种方式读取了 my.cnf 等配置文件，需借助操作系统级审计工具：
-
Linux auditd：配置规则监控文件访问
sudo auditctl -w /etc/my.cnf -p r -k mysql_config_read
后续用ausearch -k mysql_config_read查看谁触发了读操作（含 UID、进程名、命令行参数） -
inotifywait（轻量临时方案）：
inotifywait -m -e access /etc/my.cnf
可实时看到是否有进程打开了该文件，但不记录具体用户或 PID 细节 -
启用 systemd 的日志审计（若 mysqld 由 systemd 管理）：
检查journalctl -u mysql --since "2026-05-01"，关注启动/重载日志（如systemctl reload mysql），结合loginuid字段可追溯触发者
间接关联：从数据库行为反推配置变更意图
虽然不能直接审计“读配置”，但可观察配置生效后的数据库行为，辅助判断是否有人试图探测或利用配置：
- 检查
SHOW VARIABLES LIKE '%log%';或SELECT @@global.general_log;—— 频繁查询日志开关变量可能暗示试探性操作 - 监控
SET GLOBAL动态修改参数（如SET GLOBAL audit_log=ON;），这类语句会被审计日志完整记录，含执行用户、时间、IP - 留意异常的
SELECT ... FROM performance_schema.*查询，尤其是访问variables_by_thread或global_variables表，可能反映配置探查行为
安全加固建议
防止未授权访问配置文件是更根本的防护点：
- 确保
/etc/my.cnf权限为640，属主root:mysql，禁止 world-readable - 避免在配置文件中明文存放密码；改用
mysql_config_editor或密钥管理服务 - 限制能执行
systemctl reload mysql或kill -HUP的用户范围（通过 sudoers 精确授权） - 将 MySQL 配置文件纳入主机层面的 FIM（文件完整性监控）系统，如 AIDE 或 Wazuh
