MYSQL事务及存储引擎对比

Innodb存储引擎：

由于该存储引擎在事务上具有优势，即支持具有提交、回滚和崩溃恢复能力的事务安装，所以比myisam存储引擎占用更多的磁盘空间。因此需要进行频繁的更新、删除操作，同时对事务的完整性要求比较高，需要实现并发控制，此时适合使用该存储引擎。

Memory存储引擎：

该存储引擎使用内存来存储数据，因此该存储引擎的数据访问速度非常快，但是安全上没有保障,(redis也是一个内存存储引擎)。如果应用中涉及数据比较小，需要进行快速访问，则适合使用该存储引擎。

本文主要从以下四个方面来介绍mysql的事务：

1. 事务概述
2. 事务控制语句
3. 事务隔离级别
4. innodb锁机制

事务概述：

事务具有ACID四个性质来保证数据库的更新从一个一致性状态到另一个一致性状态：

原子性（atomicity）：事务中所有的操作视为一个原子单元，即对事务所进行的数据修改等操作只能是完全提交或者完全回滚。

一致性（consistency）：事务在完成时，必须使所有的数据从一种一致性状态变更为另外一种一致性状态，所有的变更都必须应用于事务的修改，以确保数据的完整性。

隔离性（insolation）：一个事物中的操作语句所做的修改必须与其他事物所做的修改相隔离。在进行事务查看数据时数据所处的状态，要么是被另一并发事务修改之前的状态，要么是被另一并发事务修改之后的状态，即当前事务不会查看由另外一个并发事务正在修改的数据。这种特性主要由锁机制实现。

持久性（durability）：事务完成之后，所做的修改对数据的影响是永久的，即使系统重启或者系统出现故障，数据仍可恢复。

REDO日志和UNDO日志：

REDO日志：

事务执行时需要将执行的事务日志写入到日志文件里，对应的文件为redo日志。当每条sql语句进行数据库更新操作时，首先将redo日志写入到日志缓冲区。当客户端执行commit命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数innodb_flush_log_at_trx_commit控制。

REDO日志对应磁盘上的ib_logfileN(ib_logfile0,ib_logfile1)文件，该文件默认为5MB，建议设置为512MB以便容纳较大的事务。在mysql崩溃恢复时会重新执行redo日志中的记录。

UNDO日志：

与redo日志相反，undo日志主要用于事务异常时的数据回滚，具体内容就是复制事务前的数据库内容到undo缓冲区，然后在合适的时间将内容刷新到磁盘。

与redo日志不同的是，磁盘上不存在单独的undo日志文件，所有的undo日志文件均存放在表空间对应的.idb数据文件中，undo日志又被成为回滚段。

Mysql事务控制语句：

START TRANSACTION | BEGIN [WORK]                  //开启一个事务
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]       //提交一个事务
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]     //回滚一个事务
SET AUTOCOMMIT = {0 | 1}    //自动提交事务开启或者关闭

查看事务的隔离级别：

show variables like ‘tx_isolation‘;

例子：commit之后才会对表进行插入

回滚之后，表不会有变动

• < 上一篇

  oracle索引总结

• 下一篇 >

  SQL Server中的索引结构与疑惑