转自 http://www.cnblogs.com/exceptioneye/p/5451960.html
MySQL作为一种关系型数据库,已被广泛应用到互联网中的诸多项目中。今天我们来讨论下事务的提交过程。
MySQL体系结构
由于mysql插件式存储架构,导致开启binlog后,事务提交实质是二阶段提交,通过两阶段提交,来保证存储引擎和二进制日志的一致。
本文仅讨论binlog未打卡状态下的提交流程,后续会讨论打开binlog选项后的提交逻辑。
测试环境
OS:WIN7
ENGINE:
bin-log:off
DB:
测试条件
set autocommit=0;
-- ---------------------------- -- Table structure for `user` -- ---------------------------- DROP TABLE IF EXISTS `user`; CREATE TABLE `user` ( `id` int(20) NOT NULL, `account` varchar(20) NOT NULL, `name` varchar(20) NOT NULL, PRIMARY KEY (`id`), KEY `id` (`id`) USING BTREE, KEY `name` (`name`) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
测试语句
insert into user values(1, 'sanzhang', '张三');
commit;
一般常用的DML:Data Manipulation Language 数据操纵语言,对表的数据进行操作,(insert、update、delete )语句 和 DCL:Data Control Language 数据库控制语言
(创建用户、删除用户、授权、取消授权)语句 和 DDL:Data Definition Language 数据库定义语言,对数据库内部的对象进行创建、删除、修改的操语句
,均是使用MySQL提供的公共接口mysql_execute_command,来执行相应的SQL语句。我们来分析下mysql_execute_command接口执行的流程:
mysql_execute_command { switch (command) { case SQLCOM_INSERT: mysql_insert(); break; case SQLCOM_UPDATE: mysql_update(); break; case SQLCOM_DELETE: mysql_delete(); break; ...... } if thd->is_error() //语句执行错误 trans_rollback_stmt(thd); else trans_commit_stmt(thd); }
从上述流程中,可以看到执行任何语句,最后都会执行trans_rollback_stmt或者trans_commit_stmt,这两个分别是语句回滚和语句提交。
语句提交,对于非自动模式下,主要有两个作用:
1、释放autoinc锁,这个锁主要用来处理多个事务互斥的获取自增序列。因此,无论最后执行的是语句提交还是语句回滚,该资源都是需要立马释放掉的。
2、标识语句在事务中的位置,方便语句级回滚。执行commit后,可以进入commit流程。
现在看下具体的事务提交流程:
mysql_execute_command trans_commit_stmt ha_commit_trans(thd, FALSE); { TC_LOG_DUMMY:ha_commit_low ha_commit_low() innobase_commit { //获取innodb层对应的事务结构 trx = check_trx_exists(thd); if(单个语句,且非自动提交) { //释放自增列占用的autoinc锁资源 lock_unlock_table_autoinc(trx); //标识sql语句在事务中的位置,方便语句级回滚 trx_mark_sql_stat_end(trx); } else 事务提交 { innobase_commit_low() { trx_commit_for_mysql(); <span style="color: #ff0000;">trx_commit</span>(trx); } //确定事务对应的redo日志是否落盘【根据flush_log_at_trx_commit参数,确定redo日志落盘方式】 trx_commit_complete_for_mysql(trx); trx_flush_log_if_needed_low(trx->commit_lsn); log_write_up_to(lsn); } } }
trx_commit trx_commit_low { trx_write_serialisation_history { trx_undo_update_cleanup //供purge线程处理,清理回滚页 } trx_commit_in_memory { lock_trx_release_locks //释放锁资源 trx_flush_log_if_needed(lsn) //刷日志 trx_roll_savepoints_free //释放savepoints } }
MySQL是通过WAL方式,来保证数据库事务的一致性和持久性,即ACID特性中的C(consistent)和D(durability)。
WAL(Write-Ahead Logging)是一种实现事务日志的标准方法,具体而言就是:
1、修改记录前,一定要先写日志;
2、事务提交过程中,一定要保证日志先落盘,才能算事务提交完成。
通过WAL方式,在保证事务特性的情况下,可以提高数据库的性能。
从上述流程可以看出,提交过程中,主要做了4件事情,
1、清理undo段信息,对于innodb存储引擎的更新操作来说,undo段需要purge,这里的purge主要职能是,真正删除物理记录。在执行delete或update操作时,实际旧记录没有真正删除,只是在记录上打了一个标记,而是在事务提交后,purge线程真正删除,释放物理页空间。因此,提交过程中会将undo信息加入purge列表,供purge线程处理。
2、释放锁资源,mysql通过锁互斥机制保证不同事务不同时操作一条记录,事务执行后才会真正释放所有锁资源,并唤醒等待其锁资源的其他事务;
3、刷redo日志,前面我们说到,mysql实现事务一致性和持久性的机制。通过redo日志落盘操作,保证了即使修改的数据页没有即使更新到磁盘,只要日志是完成了,就能保证数据库的完整性和一致性;
4、清理保存点列表,每个语句实际都会有一个savepoint(保存点),保存点作用是为了可以回滚到事务的任何一个语句执行前的状态,由于事务都已经提交了,所以保存点列表可以被清理了。
关于mysql的锁机制,purge原理,redo日志,undo段等内容,其实都是数据库的核心内容。
MySQL 本身不提供事务支持,而是开放了存储引擎接口,由具体的存储引擎来实现,具体来说支持 MySQL 事务的存储引擎就是 InnoDB。
存储引擎实现事务的通用方式是基于 redo log 和 undo log。
简单来说,redo log 记录事务修改后的数据, undo log 记录事务前的原始数据。
所以当一个事务执行时实际发生过程简化描述如下:
- 先记录 undo/redo log,确保日志刷到磁盘上持久存储。
- 更新数据记录,缓存操作并异步刷盘。
- 提交事务,在 redo log 中写入 commit 记录。
在 MySQL 执行事务过程中如果因故障中断,可以通过 redo log 来重做事务或通过 undo log 来回滚,确保了数据的一致性。
这些都是由事务性存储引擎来完成的,但 binlog 不在事务存储引擎范围内,而是由 MySQL Server 来记录的。
那么就必须保证 binlog 数据和 redo log 之间的一致性,所以开启了 binlog 后实际的事务执行就多了一步,如下:
- 先记录 undo/redo log,确保日志刷到磁盘上持久存储。
- 更新数据记录,缓存操作并异步刷盘。
- 将事务日志持久化到 binlog。
- 提交事务,在 redo log 中写入commit记录。
这样的话,只要 binlog 没写成功,整个事务是需要回滚的,而 binlog 写成功后即使 MySQL Crash 了都可以恢复事务并完成提交。
要做到这点,就需要把 binlog 和事务关联起来,而只有保证了 binlog 和事务数据的一致性,才能保证主从数据的一致性。
所以 binlog 的写入过程不得不嵌入到纯粹的事务存储引擎执行过程中,并以内部分布式事务(xa 事务)的方式完成两阶段提交。
参考
1、《高性能MySQL》