背景是客服反馈有数据被清理掉了，开始追溯日志
查看mysql是否开启日志：
show variables like '%log%';
蛋疼general_log是关闭的，继续看二进制日志有没有开启，
好消息，二进制日志是开的
从docker进入该目录 docker exec -it ......,miamiamia~~~~~~
根据系统参数查看该目录下日志文件 并使用log_bin_basename 过滤一下(当然你可以不过滤直接看，文件也不是特别多)
cd /var/lib/mysql
ls -ltrh|grep binlog
看了一下日志，pm反馈昨天数据还有，那28号之前的日志可以放弃，简单看一下日志可以在Navicat里面看，数据量很大可以放弃，直接使用mysqlbinlog命令看，因为数据有上下关联关系，最好还是用命令转成文档看好一些
show binlog events in 'binlog.000006';
找到mysqlbinlog所在目录，因为是docker镜像 文件相对来说少一些，直接用find命令过滤一下,如果是mysql的镜像的话，应该有环境变量的设置可以跳过这一步直接使用该命令即可
find / |grep mysqlbinlog
把二进制文件转为txt文本，
/usr/bin/mysqlbinlog --base64-output=DECODE-ROWS -v binlog.000006 > mysqlbin6.txt
exit退出docker镜像，开始拷贝文件到当前目录下：
docker cp 镜像id:/var/lib/mysql/mysqlbin6.txt ./
下载文件，开始分析（就是看一下被删数据的表，ctrl+f开始搜索就可以了）
这应该是在系统中使用对应功能删除的，不过日志没记录，案件暂时到这里基本可以告一段落了，确定这个时间点公司没这么勤快的人干活，应该是客户自己搞的，再追查到具体操作人就有点难看了
记录一下命令免得再来一次
