🎏：你只管努力，剩下的交给时间
🏠 ：小破站
从删库到还原
- 魔法一
- 魔法二
- 魔法三
- 魔法四
- 查看是否开启binlog，且format为row
- 执行以下命令
重要的事情说第一遍：遇到这种事情一定要冷静，别慌，先喝口水，再找到我这篇博客
相信大家第一眼看到标题也是很诧异，但是在日常工作中总是有些大佬会无意执行这样的操作，这不我就遇到好几次了
正常情况我们是没有资格执行这个删库的命令的，最多你可以执行的是delete table,update table set。
大家也肯定注意到了，这两条语句都很危险，因为没有条件。噩梦可能就是从你点击的那一刻开始，比如我这样的操作。
因为没有条件，导致整个表的数据都被改变了，当时真想哭爹喊娘。接下来我们进行一些骚操作让你复原表
重要的事情说第二遍：遇到这种事情一定要冷静，别慌，先喝口水，再找到我这篇博客
魔法一
如果你在Navicat上操作的，并且你操作的表是之前打开的，而且数据只有不到1000条(Navicat的默认分页数)，那么恭喜你，这个魔法适合你。
-
回到这个表中，你可以发现数据没变，此时千万别抱着好奇的态度，为什么没变呢，去点击刷新，一点击就完犊子了。
-
将所有数据复制为insert语句，以及update语句(双重保险)，然后你可以刷新看一下，发现数据就变为你误操作的数据了，此时你将复制好的insert以及update，执行一下(如果你执行的是delete，就用insert，如果是update就用update)
可以看下数据压根没进行更新，美滋滋。
魔法二
如果魔法一没帮到你，我们来看下魔法二。正常情况下公司是每天会备份数据库的，所以第二种方法就是恢复备份数据了。
- 找到备份的sql文件
- 不管是备份的整个库，还是单个表，都不建议在刚刚操作的数据库或者表上操作
- 执行以下命令(如果你是多实例，建议换一个实例进行sql执行，如果是单实例，建议换一个库进行操作)
mysql -u'root' -p'123456' -S /home/mysql/3306/tmp/mysql_3306.sock test -e "source /home/backup/2024-05-24-01-00-02/test.sql"
- 备份原数据，再执行数据传输
魔法三
延迟主从，这个我认为在实际工作中非常有必要的，如果一些误操作，靠这个是完全可以恢复的，至于延迟的时间就需要仔细斟酌了，几分钟到几小时都可行。当然这个也没必要说太多，比如3306上的xiaobo库中的user表被删了，但是我有3307这个从库，延迟时间是10分钟，那么我直接就可以从3307中的xiaobo.user拷贝到3306的xiaobo.user中。
魔法四
这个魔法的前提是mysql开启了binlog，且为row。
查看是否开启binlog，且format为row
要查看 MySQL 是否已启用二进制日志（binlog）且格式为 ROW，可以使用 MySQL 命令行客户端连接到 MySQL 数据库，并执行以下命令：
SHOW VARIABLES LIKE 'log_bin';
这会显示 MySQL 是否已启用二进制日志，如果结果为 ON，则表示已启用二进制日志；如果为 OFF，则表示未启用。如果启用了二进制日志，可以继续检查日志格式：
SHOW VARIABLES LIKE 'binlog_format';
如果结果为 ROW，则表示二进制日志格式为 ROW。如果结果为 STATEMENT 或 MIXED，则表示二进制日志格式为 STATEMENT 或 MIXED。
执行以下命令
mysqlbinlog --start-datetime="2024-05-24 09:52:00" --base64-output=decode-rows -vv mysql_binlog.000004
