图2.慢查询日志演示
从上述日志中“Query_time”、“Rows_examined”、“Rows_sent”、“Bytes_sent”等数值，可以确定语句的查询耗时长、扫描行数与返回值并不匹配，以及数据传输量高。导致出现此现象的原因为语句中对“order”表进行了全表查询、返回的字段数据量大、高并发环境下锁时间造成的延迟堆积等。
通过上述现象，结合慢查询带来的风险问题，就可以分析该用户日度或月度慢查询次数、查询的目标表是否存在敏感数据、以及该用户是否存在主观故意行为。
例二：二进制日志（使用chatgpt生成）
前文提到无法直接利用文本编辑器打开日志，那么如何利用mysqlbinlog打开二进制日志文件？
# 查看# 首先利用win+r，打开cmd# 随后进入安装目录下的“mysql server 8.0\bin”文件# 再用“mysqlbinlog/var/lib/文件名”进行查看# 批量查看# 在bin文件查看mysqlbinlog/var/lib/文件名/var/lib/mysql/文件名# 批量导出（请确保有足够的权限）# 在bin文件下导出mysqlbinlog --start-datetime="时间" --stop-datetime="时间" binlog.000001> exported_logs.sqlmysqlbinlog --start-position=120 --stop-position=500 binlog.000001 >exportrd_logs.sql
图2.使用mysqlbinlog工具打开的后的二进制日志
编号为901和1113的记录显示，重复插入了相同的数据，此行为会造成数据冗余，浪费储存空间，且重复的数据也可能会导致业务统计出现错误；
编号1729的操作更新了全表的所有记录，但没有添加限制条件，可能会影响无需更新的数据，且若数据量大，会引发锁表或服务器崩溃；
编号2355直接无条件删除清空了整个employees表，极易造成数据丢失。
例三：通用查询日志（使用chatgpt生成）
图3.通用查询日志部分内容
从图3中可以看出IP为192.168.1.10以及192.168.1.12的用户访问了“users”表和“sensitive”表，表中包含敏感信息，从而需要确定使用该IP的用户是否具有权限、以及通过访问时间来判断是否为正常工作时间进行的访问；
IP为192.168.1.10的用户，在01-06 12:00:03时进行了删除表的操作，需要确定此表原先的存储的内容，避免数据丢失；
IP为192.168.1.13的用户，查询了不存在的表products，这可能是代码编写错误，但也可以分析出现此类情况的次数，避免频繁错误查询，浪费数据库资源。
以上就是笔者关于MySQL数据库审查的关注点以及思路，欢迎讨论和补充~
自我学习的同时，希望也能够帮到你~
