在开篇之前，请谨记：请注意备份数据库，请注意检查数据库备份的完整性，不完整就相当于没有备份！！！
为何如此？因为博主踩到了这个坑，我们团队在为学校维护在线评测OJ平台的时候就因为这个问题，花费了我们一天的时间来恢复数据。
起因
早上的时候老师那边反馈说有几位同学无法提交代码，于是我寻思老bug了，删除之前的代码的评测记录就ok了，于是开始备份数据库、删除数据，重启前台，一顿操作猛如虎，然后发现专题的排行榜出了问题，接着整个专题也出了问题，炸锅了。
然后我就点开数据库的备份，选择一键恢复，不恢复还好，恢复了才发现出了大问题，宝塔自动备份的数据库并不完整，我们丢失了五千多条的评测记录！！！
刚好最近老师在使用平台申请精品课，这可把我们着急坏了，于是从网上找各种解决办法，最后发现了可以使用binlog来恢复数据。
BINLOG
首先要查看binlog功能是否开启了，先登陆一下数据库。
mysql -u root -p
// 接下来会提示输入root密码登陆之后是这个样子的：
然后使用如下命令来查看binlog的开启状态：
MariaDB [(none)]> show variables like 'log_%';
这个时候我们可以查看到log_bin是在开启的状态，说明我们还是很有希望去恢复数据的。
此处的mariadb是使用宝塔安装的，如果是自行安装的那么路径会稍有不同。
我们来到这个目录，可以发现最新的binlog是000029
然后我们确定一下写错的语句的大致位置, --start-datetime设置为这个时间是因为我在大概8点50之后才执行的误操作，所以，可以查看我们操作此dorp命令的时间戳，然后将binlog日志从这个时间开始到到09:10这个位置，将这个时间区间内执行的SQL语句写入/WWW/1.sql这个sql文件中。
--start-datetime：从二进制日志中读取指定等于时间戳或者晚于本地计算机的时间
--stop-datetime：从二进制日志中读取指定小于时间戳或者等于本地计算机的时间 取值和上述一样
--start-position：从二进制日志中读取指定position 事件位置作为开始。
--stop-position：从二进制日志中读取指定position 事件位置作为事件截至/www/server/mysql/bin/mysqlbinlog --start-datetime="2021-03-24 08:50:00" -stop-datetime="2021-03-24 09:10:00" > /www/1.sql然后，我们打开此文件，推荐使用vscode打开，不过这里我直接使用记事本，定位到我们错误的语句的位置，我们只需要重新执行一遍这个位置之前所有的SQL语句，就可以恢复到删除之前的状态。
我们提取这个时间戳，把他转换为时间，这个时间是我们要恢复数据位置的时间。
然后确定数据的丢失范围，也就是确认是从哪个时间开始的数据到现在时间中数据库的内容丢失了，我们就把那个时间作为开始时间。
然后在数据库执行如下命令：
/www/server/mysql/bin/mysqlbinlog --start-datetime="2021-03-18 09:06:48" -stop-datetime="2021-03-24 08:54:18" /www/server/data/mysql-bin.000029 > /www/2.sql如果你可以直接使用mysqlbinlog，那么就不必像我一样前面加上路径，如果你使用宝塔，那么可以直接参考我的写法。这里从binlog中导出的SQL语句就是这个区间内的数据执行SQL语句，相当于我们重新一条一条的把之前执行过的语句重新执行一遍，以达到恢复数据的目的。
然后我们将此sql导入数据库：
MariaDB [(none)]> use testtt // 切换到testtt数据库
Database changed
MariaDB [testtt]> source /www/2.sql 添加sql源然后回车执行即可。
如果你的数据不复杂，这个时候可能已经恢复成功了，但是博主就比较惨了，由于数据太多太过于杂乱，最终只成功恢复了三分之一的数据，最后，还是采取清空数据表，重头开始的办法了。
可能用到的
过滤数据库中的语句，只保留需要恢复表的语句：
grep -B3 -w judge_state 5.txt >judge_state1.sql左边的judge_state 是数据表名，右边为导出的文件名称。
时间戳转换工具：https://tool.lu/timestamp
最后
这是从V2EX看到的一段话：
冗余不做，十恶不赦。备份不做，日子甭过。
做不好也一样。。。。
参考
https://blog.csdn.net/king_kgh/article/details/74890381
https://blog.csdn.net/kking_edc/article/details/111149340
还有很多的记录，找不到了。
