mysql误删除数据恢复,mysql误删除一个表，可以恢复吗

mysql误删除数据恢复,mysql误删除一个表，可以恢复吗详细介绍

本文目录一览： mysql误删除一个表，可以恢复吗

1、首先构建测试环境数据create table t1(a varchar(10),b varchar(10));insert into t1 values('1','1');insert into t1 values('2','2');commit;。
2、模拟误修改，将t1表中的b字段更新为错误数据 "123456"update t1 set b='123456' where a='1';commit;select * from t1;。
3、将恢复工具上传到服务器并进行解压。unzip binlog2sql-master.zip。
4、得到误修改时的binlog文件（show binary logs;），实验环境是mysql-bin.000011。
5、通过 binlog2sql.py 脚本的到所有 对表 t1 的修改操作。python binlog2sql.py -hlocalhost -P23307 -ubinlog2sql -p'binlog2sql' -dtest -tt1 --start-file='mysql-bin.000011'。
6、得到了误删除的sql的准确位置在1382-1615之间，使用 _**-B**_ 选项生成回滚sql。python binlog2sql.py -hlocalhost -P23307 -ubinlog2sql -p'binlog2sql' -dtest -tt1 --start-file='mysql-bin.000011' --start-position=1382 --stop-position=1615 -B。
7、执行得到的回滚语句进行误操作恢复。就完成了。

mysql数据没有备份误删了怎么恢复

打开mysql的bin log功能：对于mysql也是支持增量备份，但要打开mysql的bin log功能。我们修改mysql的配置文件。linux是/etc/my.cnf，windows是mysql的安装目录/my.ini我们在[mysqld]下面加上log-bin一行代码，如下面。[mysqld]log-bin=mysql-bin复制代码加完后重起mysql即可。某客户更新数据的时候，误删了数据库的内容，因为数据库做了主从，但是没有做备份（备份很重要啊！）幸好开启了bin-log，之后只好把整个日志的记录拿回来本地进行恢复。之后自己也做了一个简单的测试，对数据进行恢复，具体如下：1、新建一个表CREATE TABLE `lynn`.`sn_test` ( `name` VARCHAR( 10 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL , `age` INT( 3 ) NOT NULL ) ENGINE=MYISAM;2、插入多条数据INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn1', '1');INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn2', '2'); INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn3', '3'); INSERT INTO `lynn`.`sn_test` (`name`, `age`) VALUES ('lynn4', '4');3、查看数据并删除mysql> select * from sn_test;+-------+-----+| name | age |+---------+---+| lynn1 | 1 || lynn2 | 2 || lynn3 | 3 || lynn4 | 4 |+---------+-----+4 rows in set (0.00 sec)mysql> delete from sn_test;Query OK, 4 rows affected (0.00 sec)mysql> select * from sn_test;Empty set (0.00 sec)4、mysqlbinlog恢复数据mysqlbinlog mysql-bin.000006 > 1.sql查看1.txt里面数据插入的纪录，把删除之前的数据进行恢复mysqlbinlog mysql-bin.000006 --start-position=2471 --stop-position=2876 | mysql -uroot -p123重新登录，查看数据，OK，已经成功恢复了对于数据库操作，应该注意如下问题：1、要常备份（全备，增量备份），出了问题可以最快恢复数据；2、操作数据库前，要把需要操作的数据库或者表dump出来；3、需要把bin-log打开，就算没有做上面的两步，也可以通过日志恢复数据mysql数据没有备份误删了怎么恢复标签：安装poslinfrom通过collateosi--isa

详解如何通过Mysql的二进制日志恢复数据库数据

经常有网站管理员因为各种原因和操作，导致网站数据误删，而且又没有做网站备份，结果不知所措，甚至给网站运营和盈利带来负面影响。所以本文我们将和大家一起分享学习下如何通过Mysql的二机制日志(binlog)来恢复数据。系统环境：操作系统：CentOS 6.5 X64 (虚拟机)；WEB服务：PHP+Mysql+apache；网站：为方便，直接在本地用蝉知系统搭建一个DEMO站点；操作步骤：1.开启binlog功能及基本操作；2.往站点添加数据；3.刷新binlog日志；4.删除数据；5.binlog日志内容解析；6.恢复指定数据；1.开启binlog功能及基本操作要使用Mysql的binlog日志功能，首先要在Mysql的配置文件中开启该功能，操作很简单。找到Mysql的配置文件，在文件中添加一行”log_bin = mysql-bin”即可。其实在我安装的各种Mysql环境中，该功能通常都是默认开启的。开启binlog功能后，在mysql的数据库目录下就会有诸如mysql-bin.000001、mysql-bin.000002等文件，这就是mysql的二进制日志文件。每当mysql启动或手动刷新日志后都会新建一个二进制日志文件。首先我们mysql命令行中，用”show master logs”命令查看已有的binlog文件。2.往站点添加数据在网站后台文章模块里，我添加了几条测试数据。3.刷新binlog日志此前mysql的binlog文件为mysql-bin.000001，并且在网站后台往数据库中添加了三篇文章。现在我们刷新binlog日志，会生成新的mysql-bin.000002文件，如下：flush logs;show master logs; 4.删除数据这里我把刚才添加的三篇文章都删除掉。5.binlog日志内容解析Mysql的二进制日志文件记录的mysql的操作，比如刚才的删除操作，我们来看下日志文件的具体内容。使用mysql的mysqlbinlog命令： mysqlbinlog /data/mysql/mysql-bin.000002注意：因为我本地mysqlbinlog无法识别binlog配置中的default-character-set=utf8，所以这里我在命令中加上了” _no-defaults”才起作用，大家引以为鉴。下面是日志内容部分截图：6.恢复指定数据；在通过mysql的binlog日志恢复数据时，我们可以指定恢复到具体时间点，这有点像服务器快照管理。所以我们现在要恢复刚才删除的那篇文章，可以从删除之前找一个时间点，并恢复到那个时间点即可。有关mysqlbinlog命令的使用方法，我们可以通过mysqlbinlog的帮助命令进行查看，如下：mysqlbinlog _no-defaults _help如帮助文档所示，可以通过指定时间或指定位置来恢复数据，这里我以指定时间为例给大家演示。我们来查看下日志文件mysql-bin.000001，如下：mysqlbinlog -no--defaults /data/mysql/mysql-bin.000001通过前面操作步骤我们知道，在删除数据之前，我们生成了mysql-bin.000002日志文件，所以我们只要恢复到这个时间点即可，上图中我已找到了这个时间。命令如下： 代码如下:mysqlbinlog _no-defaults _stop-datetime='2017-04-11 09:48:48'/data/mysql/mysql-bin.000001 |mysql _uroot _p123456这时我们在看后台，发现刚才删除的三篇文章都已恢复回来了，从而到达我们期望的目的。总结：本文和大家分享了如何通过mysql的二进制日志文件恢复数据。但还是要提醒大家，在平时要做好网站数据备份，现在的一些主流CMS建站系统都会内置数据库备份功能，比如这里我用的蝉知系统，数据是网站的命脉，做好数据备份以避免后期不必要的麻烦或损失。

详解MySQL误操作后怎样进行数据恢复_MySQL

一、开启binlog。首先查看binlog是否开启mysql> show variables like "log_bin";+---------------+-------+|Variable_name | Value +---------------+-------+| log_bin OFF +---------------+-------+1 row in set (0.00 sec)值为OFF，需开启，开启binlog方式如下：#vim /etc/my.cnf在[mysqld]中加入log-bin = mysql-binlog-bin = /usr/local/mysql/log/mysql-bin.log重启mysql服务#service mysqld stop#service mysqld start二、模拟数据写入建库create database backup;建表CREATE TABLE `number` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '编号', `updatetime` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;写入数据程序2-1#coding:utf8#python2.7import MySQLdbimport timedef connect_mysql(db_host="192.168.11.169",user="martin",passwd="martin",db="backup",charset="utf8"): conn = MySQLdb.connect(host=db_host,user=user,passwd=passwd,db=db,charset=charset) conn.autocommit(True)return conn.cursor()#数据插入for i in range(0,10):#time=time.strftime("%Y-%m-%d %H:%M:%S")sql = 'insert into number(updatetime) values(%s)'values = [(time.strftime("%Y-%m-%d %H:%M:%S"))] db1 = connect_mysql()print db1.executemany(sql,values)查询数据mysql> select * from number;+-------+------------------------+| id | updatetime +--------------------------------+| 1 | 2016-06-29 23:27:15 || 2 | 2016-06-29 23:27:15 || 3 | 2016-06-29 23:27:15 || 4 | 2016-06-29 23:27:15 || 5 | 2016-06-29 23:27:15 || 6 | 2016-06-29 23:27:15 || 7 | 2016-06-29 23:27:15 || 8 | 2016-06-29 23:27:15 || 9 | 2016-06-29 23:27:15 || 10 | 2016-06-29 23:27:15 |+-------+------------------------+10 rows in set (0.00 sec)三、全量备份mysqldump -uroot -p -F --master-data=2 backup |gzip> /martin/data/backup_$(date +%F).sql.gz注：加-F能刷新binlog，方便恢复时操作。四、模拟写入增量数据继续执行程序2-1。查询数据mysql> select * from number;+----+---------------------------+| id | updatetime |+----+---------------------------+| 1 | 2016-06-29 23:27:15 || 2 | 2016-06-29 23:27:15 || 3 | 2016-06-29 23:27:15 || 4 | 2016-06-29 23:27:15 || 5 | 2016-06-29 23:27:15 || 6 | 2016-06-29 23:27:15 || 7 | 2016-06-29 23:27:15 || 8 | 2016-06-29 23:27:15 || 9 | 2016-06-29 23:27:15 || 10 | 2016-06-29 23:27:15 || 11 | 2016-06-29 23:31:03 || 12 | 2016-06-29 23:31:03 || 13 | 2016-06-29 23:31:03 || 14 | 2016-06-29 23:31:03 || 15 | 2016-06-29 23:31:03 || 16 | 2016-06-29 23:31:03 || 17 | 2016-06-29 23:31:03 || 18 | 2016-06-29 23:31:03 || 19 | 2016-06-29 23:31:03 || 20 | 2016-06-29 23:31:03 |+-------+---------------------+20 rows in set (0.00 sec)五、增量备份保留mysql-bin.000002及之后的binlog即可。六、模拟误操作delete from number;七、再次写入增量数据执行程序2-1select * from bumber;+------+------------------------+| id | updatetime |+------+------------------------+| 21 | 2016-06-29 23:41:06 || 22 | 2016-06-29 23:41:06 || 23 | 2016-06-29 23:41:06 || 24 | 2016-06-29 23:41:06 || 25 | 2016-06-29 23:41:06 || 26 | 2016-06-29 23:41:06 || 27 | 2016-06-29 23:41:06 || 28 | 2016-06-29 23:41:06 || 29 | 2016-06-29 23:41:06 || 30 | 2016-06-29 23:41:06 |+------+------------------------+10 rows in set (0.00 sec)八、恢复此时发现之前的delete操作为误操作，急需恢复，恢复过程如下给该表加上读锁lock table number read;将全量备份的数据导入#cd /martin/data/#gzip -d number_2016-06-29.sql.gz#grep -i "change" *.sql-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=107;刷新日志#mysqladmin -uroot -p'martin' flush-logs#cd /usr/local/mysql/log#ls|grep mysql-bin|grep -v indexmysql-bin.000001mysql-bin.000002mysql-bin.000003可确定mysql-bin.000002为增量数据binlog导入全量备份#cd /martin/data/#mysql -uroot -p backup #cp /usr/local/mysql/log/mysql-bin.000002 /martin/data/#mysqlbinlog mysql-bin.000002 >bin.sql#vim bin.sql在bin.sql找到之前的delete语句，删除mysql -uroot -p 九、确认已恢复数据登录mysql#mysql -uroot -p'martin' backupselect * from number;+----+---------------------+| id | updatetime |+----+---------------------+| 1 | 2016-06-29 23:27:15 || 2 | 2016-06-29 23:27:15 || 3 | 2016-06-29 23:27:15 || 4 | 2016-06-29 23:27:15 || 5 | 2016-06-29 23:27:15 || 6 | 2016-06-29 23:27:15 || 7 | 2016-06-29 23:27:15 || 8 | 2016-06-29 23:27:15 || 9 | 2016-06-29 23:27:15 || 10 | 2016-06-29 23:27:15 || 11 | 2016-06-29 23:31:03 || 12 | 2016-06-29 23:31:03 || 13 | 2016-06-29 23:31:03 || 14 | 2016-06-29 23:31:03 || 15 | 2016-06-29 23:31:03 || 16 | 2016-06-29 23:31:03 || 17 | 2016-06-29 23:31:03 || 18 | 2016-06-29 23:31:03 || 19 | 2016-06-29 23:31:03 || 20 | 2016-06-29 23:31:03 || 21 | 2016-06-29 23:41:06 || 22 | 2016-06-29 23:41:06 || 23 | 2016-06-29 23:41:06 || 24 | 2016-06-29 23:41:06 || 25 | 2016-06-29 23:41:06 || 26 | 2016-06-29 23:41:06 || 27 | 2016-06-29 23:41:06 || 28 | 2016-06-29 23:41:06 || 29 | 2016-06-29 23:41:06 || 30 | 2016-06-29 23:41:06 |+----+---------------------+30 rows in set (0.00 sec)恢复完成！

mysql逻辑删除如何恢复

在项目中，一般会遇到这种情况：逻辑删除以及多关联不删除逻辑删除（软删除）：逻辑删除就是对要被删除的数据打上一个删除标记，通常使用一个is_deleted字段标示行记录是不是被删除（或者使用一个status字段代表所谓的“删除”状态），在逻辑上是数据是被删除的，但数据本身是依然存在的。推荐课程：MySQL教程。在前端页面中删除了，也不显示了，其实数据库中并没有删除，只是根据了一个状态字段，0启动，1停用的思路来达成。所以逻辑删除就是只是将一个名为status字段进行更改，来达到前端页面是否显示的方式，其数据本身并没有被删除，想要恢复只需要改回status字段即可。思路：在XML中写查询SQL时，多加一个条件，库中的状态字段SELECT * FROM md_drainage_basin

and basin_name LIKE concat('%',#{basinName},'%')

AND state = #{state}

ORDER BY sort_order那我们给前端页面时候的数据，就要自己在Java代码中进行默认操作，因为前端是不会在查询的传一个状态码的，后台自己生成mdDrainageBasin.setState(0);List

list = mdDrainageBasinMapper.findByQuery(mdDrainageBasin);默认把状态0启动set到实体类中，再进行查询，这样前端看到的只有状态为0的数据逻辑删除是把状态码进行更新，更新成1，调用update而不是delete，但考虑到多表关系，例如流域下面挂着水系，逻辑删除一条流域，那下面的水系也要进行逻辑删除不给与显示，这时可根据判断，如果流域下面有相应水系，则不删除，不然删除MdDrainageBasin mdDrainageBasin = mdDrainageBasinService.findById(id);List

list = mdWaterSystemMapper.findByWater(mdDrainageBasin.getBasinCode());if (list.size() > 0) { return ResponseMsgUtil.failure();} else { mdDrainageBasin.setState(1); mdDrainageBasinService.update(mdDrainageBasin); return ResponseMsgUtil.success(mdDrainageBasin);}根据前端传入的Id进行查询哪一条流域，这条流域下面有多少水系，有水系，不删除，没水系，删除

mysql如何利用binlog进行数据恢复详解

参数说明 --no-defaults 为了防止报错：mysqlbinlog: unknown variable 'default_character_set=utf8mb4' --base64-output='decode-rows' 和-v一起使用， 进行base64解码 其他有很多用来限定范围的参数，比如数据库，起始时间，起始位置等等。这些参数在查找误操作的时候非常有用。binlog的基本块如下：# at 417750#181007 1:50:38 server id 1630000 end_log_pos 417844 CRC32 0x9fc3e3cd Query thread_id=440109962 exec_time=0 error_code=0SET TIMESTAMP=1538877038/*!*/;BEGIN1、# at 417750指明的当前位置相对文件开始的偏移位置，这个在mysqlbinlog命令中可以作为--start-position的参数2、#181007 1:50:38 server id 1630000 end_log_pos 417844 CRC32 0x9fc3e3cd Query thread_id=440109962 exec_time=0 error_code=0181007 1:50:38指明时间为18年10月7号1:50:38，serverid也就是你在配置文件中的配置的，end_log_pos 417844，这个块在417844结束。thread_id执行的线程id，exec_time执行时间，error_code错误码3、SET TIMESTAMP=1538877038/!/;BEGIN具体的执行语句一行记录产生的日志如下所示# at 417750#181010 9:50:38 server id 1630000 end_log_pos 417844 CRC32 0x9fc3e3cd Query thread_id=440109962 exec_time=0 error_code=0SET TIMESTAMP=1539136238/*!*/;BEGIN/*!*/;# at 417844#181010 9:50:38 server id 1630000 end_log_pos 417930 CRC32 0xce36551b Table_map: `goods`.`good_info` mapped to number 129411# at 417930#181010 9:50:38 server id 1630000 end_log_pos 418030 CRC32 0x5827674a Update_rows: table id 129411 flags: STMT_END_F### UPDATE `goods`.`good_info`### WHERE### @1='2018:10:07' /* DATE meta=0 nullable=0 is_null=0 */### @2=9033404 /* INT meta=0 nullable=0 is_null=0 */### @3=1 /* INT meta=0 nullable=0 is_null=0 */### @4=8691108 /* INT meta=0 nullable=0 is_null=0 */### @5=9033404 /* INT meta=0 nullable=0 is_null=0 */### @6=20 /* LONGINT meta=0 nullable=0 is_null=0 */### @7=1538877024 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */### SET### @1='2018:10:07' /* DATE meta=0 nullable=0 is_null=0 */### @2=9033404 /* INT meta=0 nullable=0 is_null=0 */### @3=1 /* INT meta=0 nullable=0 is_null=0 */### @4=8691108 /* INT meta=0 nullable=0 is_null=0 */### @5=9033404 /* INT meta=0 nullable=0 is_null=0 */### @6=21 /* LONGINT meta=0 nullable=0 is_null=0 */### @7=1538877024 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */# at 418030#181010 9:50:38 server id 1630000 end_log_pos 418061 CRC32 0x468fb30e Xid = 212760460521COMMIT/*!*/;# at 418061一行记录产生的日志如上所示。以SET TIMESTAMP=1539136238/*!*/;开始，以COMMIT/*!*/;结尾。我们可以根据两个at指明的位置来限定范围。注意一条记录开始的SET TIMESTAMP之前的# at 417750和结尾的COMMIT之后的# at 418061利用binlog2sqlbinlog2sql官网介绍：从MySQL binlog解析出你要的SQL。根据不同选项，你可以得到原始SQL、回滚SQL、去除主键的INSERT SQL等。基本使用如下：python binlog2sql.py -hlocalhost -P3306 -udev -p'\*' -d room -t room_info --start-file='mysql-bin.011012' --start-position 129886892 --stop-position 130917280 > rollback.sql具体的使用我就不讲解了github上讲解的十分清楚，主要看下很多用来筛选的条件，比如起止时间--start-datetime/--stop-datetime，表名限定-t，数据库限定-d，语句限定--sql-type，主要说说我遇到的一些问题。mysql的binlog模式这里需要设置为ROW，因为ROW模式有原来的信息，如果可以直接利用binlog2sql反向生成回滚sql，如果是STATEMENT无法生成，需要利用的mysql定时备份的文件再去做回滚恢复数据的具体操作因为当时线上执行的是一条update语句，没有唯一键索引的。导致有两千多条记录被更新。语句如下：update room_info set status=1 where status=2; 根据操作时间先定位对应的binlog文件 我记得当时操作的时间大概的是上午9多左右，所以去找对应的binlog文件最后修改时间大于9点并且时间最接近的一个文件。使用linux的ll命令查看文件的修改时间。 筛选具体的数据库 因为一个mysql实例的所有binlog文件是在一个文件中的，所以我们先要去除其他不想关的数据库。利用-d参数来指明数据实例。然后在利用开始时间(--start-datetime)和结束时间(--stop-datetime)来进一步筛选 mysqlbinlog --no-defaults -v --base64-output='decode-rows' -d room --start-datetime='2018-10-10 9:00:00' --stop-datetime='2018-10-10 10:00:00' mysql-bin.011012>temp.sql 压缩取回文件分析zip temp.zip temp.sql && sz temp.zip 取回文件在本地用文本工具如vscode分析，里面有正则匹配，根据你改动过的特征，比如我有个房间号888888，这个不应该被修改，你就查看这个房间号的修改记录，ROW模式的语句是Where在前，set在后。利用正则room_id=888888.*show_state=1.*AND show_state=2很快就能匹配到。我当时的语句影响了两千多条记录，你根据找到的语句去找开始的SET TIMESTAMP=1539136238的位置之前的at和结尾的COMMIT之后的at。 利用binlog2sql生成回滚语句python binlog2sql.py -hlocalhost -P3306 -udev -p'*' -d room -t room_info -B --start-file='mysql-bin.011012' --start-position 129886892 --stop-position 130917280 > rollback.sql另外因为我这边是一条update影响多条的情况，如果是带唯一键的情况下，影响的只有一条记录，完全没必要这么麻烦，直接利用binlog2sql带上-d和-t参数限定数据库和表，然后利用grep来查找，直接可以得出对应的sql。mysqlbinlog少了一个限定表和限定语句的功能。比如精确到一张表的Delete语句，能减少很多的数据，能快速定位。总结

如何恢复mysql表中清除的数据

以下情况可以恢复数据：
1 innodb引擎表开启了事务，执行dml语句，比如delete、update、insert之类，并且没有提交即commit操作的话，可以执行rollback进行回滚恢复。如果是ddl操作，如drop、create、alter之类的操作时无效的
2 在进行删除操作之前有备份，比如mysqldump，物理备份数据文件之类的操作，那么可以恢复到删除前的数据
3 如果你的删除操作是直接对data下的文件进行删除，注意，不是粉碎文件操作，那么你可以尝试用磁盘恢复软件来找回被误删的数据文件；
除以上情况，其他真的是没法恢复了，不过貌似很多公司号称能够恢复，要收费，具体他们怎么恢复我就不晓得了。
1、第一步，查询语句：select* from table_name;或select * from table_name where [条件]
2、第二步，增加语句或插入数据insert into table_name (clus...) values(values...)实例如图：
3、修改数据：update tablename set xx=xx,xxx=xx where xxx=xxx and xxx=xxx;
4、第四步， 删除语句delete table_name where 条件实例如图：

mysql数据表内容删除后怎么恢复

在解决的过程中，以下几种尝试：
1.如果开启了日志，直接mysqlbinlog 使用日志恢复即可。
2.如果不是删除了一个表的部分数据，而是删除整个表，那么可以在删除后马上用磁盘数据恢复软件尝试恢复。（因为删除表后会有文件被删除，而删除表的部分数据，文件还是存在）
3.找数据恢复的公司，使用工具分析ibdata1（分析过程参考一页一页查看有没有历史记录存在，使用ibdata1恢复数据，应该是在了解数据表结构的前提下，数据库除ibdata1外其他数据受损不能正常使用数据库时尝试，而不是删了表数据后恢复什么的。（事实上，这个文件是存储现有表数据的，其实也可以设置成每个表一个文件。）
4.mysql下有ib_logfile0和ib_logfile1两个文件，其实这两个文件里，记录了Mysql的一些事物日志，用于事务的前滚后滚，是Mysql自身使用的，这个文件用文本工具打开后，有很多乱码，但却可以查找到被删除的少量数据的insert记录，极少数的乱码通过前后语句找出了原文，最终通过事物日志恢复了删除的文件。
注：用事物日志恢复，需要几个前提。
1：知道被删除数据的大概位置，不要这边查找，那边又不断有新数据插入。
2：因为有很多乱码，适用于查找少量数据，而不是用作大量数据的恢复，浪费体力。
3：如果二进制日志没开，没有备份，那么只能用这种方法恢复了。

mysql删除数据恢复

利用之前的备份进行恢复；
如果开启了binlog日志，并且所有日志都保持好了，可以通过回滚日志中的SQL语句进行数据恢复。