MYSQL数据库误删除数据处理

MYSQL数据库误删除怎么办

MYSQL数据库中数据的误删除恢复，网上的教程大部分都是基于binlog日志的恢复。而在未开启binlog日志的情况下，其实数据也是可以恢复的，不过这种条件下需要一些特殊手段进行恢复。这里我们简单介绍一下binlog日志开启和未开启时的恢复方案

一、开启binlog时

binlog日志文件，是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…等操作）以及表数据修改（INSERT、UPDATE、DELETE…等操作）的二进制日志，会在日志中详细记录数据库表结构变更详情及表数据修改的详细内容。

如果没有开启binlog日志功能，运行此语句则会显示
ERROR 1381 (HY000): You are not using binary logging

找到binlog日志文件之后，可以使用MYSQL自带的mysqlbinlog工具查看binlog日志

mysql>mysqlbinlog /mysql/data/mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#210802 15:16:11 server id 1918  end_log_pos 123 CRC32 0x6b83e18a       Start: binlog v 4, server v 5.7.32-log created 210802 15:16:11 at startup
ROLLBACK/*!*/;
BINLOG '
u5sHYQ9+BwAAdwAAAHsAAAAAAAQANS43LjMyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAC7mwdhEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AYrhg2s=
'/*!*/;
# at 123
#210802 15:16:11 server id 1918  end_log_pos 154 CRC32 0xeb0d0649       Previous-GTIDs
# [empty]
# at 154
#210802 15:16:49 server id 1918  end_log_pos 219 CRC32 0xfa8ab1ff       Anonymous_GTID  last_committed=0        sequence_number=1       rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
#210802 15:16:49 server id 1918  end_log_pos 316 CRC32 0x28719977       Query   thread_id=2     exec_time=0     error_code=0
SET TIMESTAMP=1627888609/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP DATABASE `test1`
/*!*/;
# at 316
#210804 13:38:30 server id 1918  end_log_pos 339 CRC32 0xa510ff89       Stop
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

输出的信息中心，# at 4 即为事务的开始偏移值

另外可以添加参数’-s’，在输出中只显示语句

mysql>mysqlbinlog -s /mysql/data/mysql-bin.000001
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
ROLLBACK/*!*/;
# [empty]
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
SET TIMESTAMP=1627888609/*!*/;
SET @@session.pseudo_thread_id=999999999/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=45,@@session.collation_connection=45,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
DROP DATABASE `test1`
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

如果误删除丢失的数据量不多，可以使用mysql>mysqlbinlog -s /mysql/data/mysql-bin.000001 > binlog.txt命令将语句保存到文件中，在文件中搜索insert语句，找到丢失数据。
若整个数据库或者表被删除，丢失数据量较多，可以使用mysqlbinlog工具，直接从binlog日志还原全部数据。
先查看binlog日志，找到事务的起始偏移值，和误操作事务前的偏移值，设置–start-position参数为事务起始偏移值，–stop-position为误操作事务开始前一个事务的偏移值

mysqlbinlog --start-position=4 --stop-position=154 /mysql/data/mysql-bin.000001 | mysql -uroot -p123456

根据binlog日志文件名称id，从小到大依次运行binlog日志文件，完成数据恢复

二、未开启binlog日志

当数据库未开启binlog日志，发生数据丢失的情况时，不要慌，尽量保证环境的原始性，不要在数据库所在分区继续写入数据，不要常使用旧的备份去还原，第一时间保护现场环境。
如果是drop了表或数据库，那么表文件将会被全部删除，需要从存储介质底层去打捞数据表页，直接解析数据表页，提取出数据记录，再写入到新的数据库中
如果是delete了部分数据记录，那么要保证此数据表不再有新的数据写入。被删除的这部分数据记录起始还存在于表文件中，只是被数据库屏蔽，可以通过底层打捞的方式，突破数据库的屏蔽，从表文件中打捞出这些被删除的数据记录。
如果是truncate了数据表，那么这个时候虽然表文件看起来还存在，但实际上表文件已经被截断，部分数据表页已经被释放至文件系统的空闲空间，同样要保证数据库所在分区的无数据写入，从存储介质底层去打捞数据表页，解析数据表页，提取出数据记录，再写入到新的数据库中

无binlog日志时的mysql删除数据恢复较为复杂，如有需要，可以留言或私信