mysql如何快速回滚

我们经常会遇到 *** 作一张大表，发现 *** 作时间过长或影响在线业务了，想要回退大表 *** 作的场景。在我们停止大表 *** 作之后，等待回滚是一个很漫长的过程，尽管你可能对知道一些缩短时间的方法，处于对生产环境数据完整性的敬畏，也会选择不做介入。最终选择不作为的原因大多源于对 *** 作影响的不确定性。实践出真知，下面针对两种主要提升事务回滚速度的方式进行验证，一种是提升 *** 作可用内存空间，一种是通过停实例，禁用 redo 回滚方式进行进行验证。

仔细阅读过官方手册的同学，一定留意到了对于提升大事务回滚效率，官方提供了两种方法：一是增加 innodb_buffer_pool_size 参数大小，二是合理利用 innodb_force_recovery=3 参数，跳过事务回滚过程。第一种方式比较温和，innodb_buffer_pool_size 参数是可以动态调整的，可行性也较高。第二种方式相较之下较暴力，但效果较好。

两种方式各有自己的优点，第一种方式对线上业务系统影响较小，不会中断在线业务。第二种方式效果更显著，会短暂影响业务连续，回滚所有没有提交的事务。

mysql命令行下怎样实现数据的回滚 *** 作

在MySQL有时执行了错误的update或者delete时导致大量数据错误恢复的办法。执行时没有开启事务，也没有对数据进行。这时就需要使用到sqlbinlog工具。

sqlbinlog需要开启，具体的打开方法就不说了。

使用sqlbinlog会产生bin文件，恢复就需要用到这些文件。文件中记录着数据库的所有 *** 作。（此方法的 *** 作是将数据库之前所执行的语句重新执行一次，以达到恢复效果）

具体步骤：1，先找到bin文件，一般都是在mysql的data文件夹中，结尾以.00000X等形式结束。

2，寻找需要还原的时间点 使用语句 mysqlbinlog 文件名 例（MySQLbinlog xxbin.000001）来查看内容，然后找到对应的具体时间

3，导出sql语句，使用语句 mysqlbinlog 文件名>sql文件路径例(mysqlbinlog xxxbin,00001>>a.sql | mysql -u root -p )

如果需要指定时间导出--start--date -stop='' --date='' 来导出指定时间执行的语句例(sqlbinlog --start-stop='2015-11-22 10:00:00' xxbin.000001>a.sql | mysql -u root -p )这句意思是导出在2015-11-22 10点之前的语句，反之start是导出时间之后的。 start和stop可以同时使用。

如果存在多个bin文件，则按照需要导出。

4，使用mysql将导出的语句执行一次。

MySQL8.0 开始支持原⼦ DDL(atomic DDL)，数据字典的更新，存储引擎 *** 作，写⼆进制日志结合成了一个事务。在没有原⼦DDL之前，DROP TABLE test1,test2；如遇到server crash，可能会有test1被drop了，test2没有被drop掉。下面来看下在MySQL8.0之前和MySQL8.0 数据字典的区别

在MySQL8.0 之前，Data Dictionary除了存在与.FRM, .TRG, .OPT ⽂件外，还存在于系统表中（MyISAM ⾮事务引擎表中），在MySQL8.0 ，Data Dictionary 全部存在于Data Dictionary Storage Engine（即 InnoDB表中），这使crash recovery 维持原⼦性成为了可能

存储引擎⽀持

目前，只有InnoDB存储引擎⽀持原子DDL，为了实现原子DDL，Innodb要写DDL logs 到 mysql.innodb_ddl_log 表，这是⼀个隐藏在mysql.ibd 数据字典表空间⾥的数据字典表。要看mysql.innodb_ddl_log 中的内容，需要

SET GLOBAL LOG_ERROR_VERBOSITY=3（MySQL 8.0 默认为2，error log 记录Errors and

warnings，不不记录notes）

SET GLOBAL innodb_print_ddl_logs=1

CREATE TABLE t1 (c1 INT) ENGINE = InnoDB

查看error log

[Note] [MY-011066] InnoDB: DDL log insert : [DDL record: DELETE SPACE, id=30,

thread_id=25, space_id=9, old_file_path=./test/t1.ibd]

[Note] [MY-011066] InnoDB: DDL log delete : by id 30

[Note] [MY-011066] InnoDB: DDL log insert : [DDL record: REMOVE CACHE, id=31,

thread_id=25, table_id=1066, new_file_path=test/t1]

[Note] [MY-011066] InnoDB: DDL log delete : by id 31

[Note] [MY-011066] InnoDB: DDL log insert : [DDL record: FREE, id=32, thread_

id=25, space_id=9, index_id=143, page_no=4]

[Note] [MY-011066] InnoDB: DDL log delete : by id 32

[Note] [MY-011066] InnoDB: DDL log post ddl : begin for thread id : 25

[Note] [MY-011066] InnoDB: DDL log post ddl : end for thread id : 25

原子DDL *** 作步骤

准备：创建所需的对象并将DDL⽇志写入 mysql.innodb_ddl_log表中。DDL日志定义了如何前滚和回滚DDL *** 作。

执行：执⾏DDL *** 作。例如，为CREATE TABLE *** 作执⾏创建。

提交：更新数据字典并提交数据字典事务。

Post-DDL：重播并从mysql.innodb_ddl_log表格中删除DDL⽇志。为确保回滚可以安全执⾏⽽不引⼊不⼀致性，在此最后阶段执⾏⽂件 *** 作（如重命名或删除数据文件）。这一阶段还从 mysql.innodb_dynamic_metadata的数据字典表删除的动态元数据为了DROP TABLE，TRUNCATE和其它重建表的DDL *** 作。

⽆论事务是提交还是回滚，DDL日志都会mysql.innodb_ddl_log在Post-DDL阶段重播并从表中删除 。mysql.innodb_ddl_log如果服务器在DDL *** 作期间暂停，DDL⽇志应该只保留在表中。在这种情况下，DDL⽇志会在恢复后重播并删除。

在恢复情况下，当服务器重新启动时，可能会提交或回退DDL事务。如果在重做⽇志和⼆进制日志中存在DDL *** 作的提交阶段期间执⾏的数据字典事务，则该 *** 作被认为是成功的并且被前滚。否则，在InnoDB重放数据字典重做日志时回滚不完整的数据字典事务 ，并且回滚DDL事务。

原⼦DDL ⽀持类型

• DROP TABLES , all tables dropped or none

• DROP SCHEMA, all entities in the schema are dropped, or none

• Note that atomic DDL statements will be rolled back or committed even in case of crash, e.g. RENAME TABLES

• CREATE TABLE would be successfully committed or rolled back (no orphan ibd left)

• TRUNCATE TABLE (including InnoDB tables with FTS AUX tables) would be successfully committed or rolled back

• RENAME TABLES, all or none

• ALTER TABLE successful or not done

示例

请点击输入图片描述

请点击输入图片描述

结论

在MySQL8.0之前，alter table *** 作在server crash的情况下，会遗留.frm,.ibd文件。MySQL8.0 能实现原⼦DDL（包括 DROP TABLE, DROP SCHEMA, CREATE TABLE, TRUNCATE TABLE, ALTER TABLE），alter table *** 作，在server crash的情况下，不会遗留.frm，.ibd临时文件。让我们⼀起期待MySQL8.0 GA的到来吧！

---