嘿，这个问题我之前帮不少人处理过——没开通用日志确实有点棘手，但咱们先从最有可能的突破口开始排查：

1. 先确认二进制日志（binlog）是否开启 #

MySQL的binlog是记录所有数据变更操作的核心日志，很多环境下默认是开启的（取决于你的配置），它里面会明确记录执行操作的用户信息。先登录MySQL执行这条命令确认：

SHOW VARIABLES LIKE 'log_bin';

如果返回值是ON，那你运气不错；要是OFF，这条线索就断了，只能看后面的间接方法。

2. 用binlog定位删除操作和执行用户 #

如果binlog是开启的，按下面步骤来：

• 先列出所有存在的binlog文件：

  SHOW BINARY LOGS;
  

• 根据你说的“两天前”确定大致时间范围，找到对应的binlog文件。然后用服务器终端的mysqlbinlog工具解析这个文件，过滤出删除表的语句（比如DROP TABLE），同时查看关联的用户信息。

举个实际的命令例子（记得替换时间和文件路径）：

mysqlbinlog --start-datetime='2024-05-20 00:00:00' --stop-datetime='2024-05-22 23:59:59' /var/lib/mysql/binlog.000001 | grep -i -B5 -A5 "drop table"

解析结果里会出现类似#1689012345 user: jsmith@192.168.1.100这样的行，这就是执行删除操作的用户名和来源主机。

3. 如果binlog也没开，试试这些间接线索 #

要是binlog也没开启，那只能找一些间接的痕迹，成功率不高，但值得一试：

• 查看MySQL的错误日志：Linux环境下通常是/var/log/mysqld.log，搜索两天内的日志，看看有没有用户登录、权限变更或者异常操作的记录，里面可能会提到相关用户。
• 检查服务器系统日志：比如/var/log/auth.log或/var/log/secure（不同发行版可能不同），查找两天内连接MySQL默认端口3306的IP地址，再结合MySQL的用户列表（SELECT user, host FROM mysql.user;）排查可疑对象。
• 第三方工具或自定义审计：如果你之前部署过审计插件（比如MySQL Enterprise Audit）或者自己建了审计表记录操作，那可以从这里查，但如果没有的话，这步就帮不上忙了。

最后提个醒 #

这次排查完后，建议至少开启binlog，最好配置通用日志或者审计工具，不然下次再遇到这种情况，真的很难追踪了。

内容的提问来源于stack exchange，提问作者Irfi