网站总是打不开,网站页脚模板,网站快照时间,上饶市建设局官方网站前言如果有人问你“数据库事务有哪些特性”#xff1f;你可能会很快回答出原子性、一致性、隔离性、持久性即ACID特性。那么你知道InnoDB如何保证这些事务特性的吗#xff1f;如果知道的话这篇文章就可以直接跳过不看啦(#^.^#)先说结论#xff1a;redo log重做日志用来保证事…前言如果有人问你“数据库事务有哪些特性”你可能会很快回答出原子性、一致性、隔离性、持久性即ACID特性。那么你知道InnoDB如何保证这些事务特性的吗如果知道的话这篇文章就可以直接跳过不看啦(#^.^#)先说结论redo log重做日志用来保证事务的持久性undo log回滚日志保证事务的原子性undo logredo log保证事务的一致性锁(共享、排他)用来保证事务的隔离性重做日志 redo log重做日志 redo log 分为两部分一部分是内存中的重做日志缓冲(redo log buffer)是易丢失的二部分是重做日志文件(redo log file)是持久的。InnoDB通过Force Log at Commit机制来实现持久性当commit时必须先将事务的所有日志写到重做日志文件进行持久化待commit操作完成才算完成。InnoDB在下面情况下会将重做日志缓冲的内容写入重做日志文件master thread 每一秒将重做日志缓冲刷新到重做日志文件;每个事务提交时当重做日志缓冲池剩余空间小于1/2时为了确保每次日志都写入重做日志文件在每次将日志缓冲写入重做日志文件后InnoDB存储引擎都需要调用一次fsync(刷盘)操作。但这也不是绝对的。用户可以通过修改innodb_flush_log_at_trx_commoit参数来控制重做日志刷新到磁盘的策略这个可以作为大量事务提交时的优化点。1参数默认值表示事务提交时必须调用一次fsync操作。0表示事务提交时重做日志缓存并不立即写入重做日志文件而是随着Master Thread的间隔进行fsync操作。2表示事务提交时将重做日志写入重做日志文件但仅写入文件系统的缓存中不进行fsync操作。fsync的效率取决于磁盘的性能因此磁盘的性能决定了事务提交的性能也就是数据库的性能。所以如果有人问你如何优化Mysql数据库的时候别忘了有硬件这一条让他们提升硬盘配置换SSD固态硬盘重做日志都是以512字节进行存储的称之为重做日志块与磁盘扇区大小一致这意味着重做日志的写入可以保证原子性不需要doublewrite技术。它有以下3个特性重做日志是在InnoDB层产生的重做日志是物理格式日志记录的是对每个页的修改重做日志在事务进行中不断被写入而且是顺序写入回滚日志 undo log为了满足事务的原子性在操作任何数据之前首先将数据备份到一个地方(这个存储数据备份的地方称为Undo Log)然后进行数据的修改。如果出现了错误或者用户执行了 ROLLBACK语句系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。undo log实现多版本并发控制(MVCC)来辅助保证事务的隔离性。回滚日志不同于重做日志它是逻辑日志对数据库的修改都逻辑的取消了。当事务回滚时它实际上做的是与先前相反的工作。对于每个INSERTInnoDB存储引擎都会完成一个DELETE对于每个UPDATEInnoDB存储引擎都会执行一个相反的UPDATE。事务提交后并不能马上删除undo log这是因为可能还有其他事务需要通过undo log 来得到行记录之前的版本。故事务提交时将undo log 放入一个链表中是否可以删除undo log 根据操作不同分以下2种情况Insert undo log insert操作的记录只对事务本身可见对其他事务不可见(这是事务隔离性的要求),故该undo log可以在事务提交后直接删除。不需要进行 purge操作。update undo log记录的是对 delete和 update操作产生的 undo log。该undo log可能需要提供MVCC机制因此不能在事务提交时就进行删除。提交时放入undo log链表,等待 purge线程进行最后的删除。锁事务的隔离性的实现原理就是锁因而隔离性也可以称为并发控制、锁等。事务的隔离性要求每个读写事务的对象对其他事务的操作对象能互相分离。再者比如操作缓冲池中的LRU列表删除添加、移动LRU列表中的元素为了保证一致性那么就要锁的介入。锁的类型InnoDB主要有2种锁行级锁意向锁行级锁共享锁(读锁 S)允许事务读一行数据。事务拿到某一行记录的共享S锁才可以读取这一行并阻止别的事务对其添加X锁。共享锁的目的是提高读读并发。排它锁(写锁 X)允许事务删除一行数据或者更新一行数据。事务拿到某一行记录的排它X锁才可以修改或者删除这一行。排他锁的目的是为了保证数据的一致性。行级锁中除了S和S兼容其他都不兼容。意向锁意向共享锁(读锁 IS )事务想要获取一张表的几行数据的共享锁事务在给一个数据行加共享锁前必须先取得该表的IS锁。意向排他锁(写锁 IX)事务想要获取一张表中几行数据的排它锁事务在给一个数据行加排他锁前必须先取得该表的IX锁。解释一下意向锁The main purpose of IX and IS locks is to show that someone is locking a row, or going to lock a row in the table.意向锁的主要用途是为了表达某个事务正在锁定一行或者将要锁定一行数据。e.g:事务A要对一行记录r进行上X锁那么InnoDB会先申请表的IX锁再锁定记录r的X锁。在事务A完成之前事务B想要来个全表操作此时直接在表级别的IX就告诉事务B需要等待而不需要在表上判断每一行是否有锁。意向排它锁存在的价值在于节约InnoDB对于锁的定位和处理性能。另外注意了除了全表扫描以外意向锁都不会阻塞。锁的算法InnoDB有三种行锁的算法Record Lock单个行记录上的锁Gap Lock间隙锁锁定一个范围而非记录本身Next-Key Lock结合Gap Lock和Record Lock锁定一个范围并且锁定记录本身。主要解决的问题是REPEATABLE READ隔离级别下的幻读。可以参考文章了解事务隔离级别的相关知识点。这里主要讲一下Next-Key Lock利用Next-key Lock锁定的不是单个值而是一个范围他的目的就是为了阻止多个事务将记录插入到同一范围内从而导致幻读。注意了如果走唯一索引那么Next-Key Lock会降级为Record Lock即仅锁住索引本身而不是范围。也就是说Next-Key Lock前置条件为事务隔离级别为RR且查询的索引走的非唯一索引、主键索引。下面我们用个例子详细说一下。首先建立一张表CREATE TABLE T (id int ,f_id int,PRIMARY KEY (id), KEY(f_id)) ENGINEInnoDB DEFAULT CHARSETutf8insert into T SELECT 1,1;insert into T SELECT 3,1;insert into T SELECT 5,3;insert into T SELECT 7,6;insert into T SELECT 10,8;事务A执行如下语句SELECT * FROM T WHERE f_id 3 FOR UPDATE这时SQL语句走非唯一索引因此使用Next-Key Locking加锁并且有2个索引其需要分别进行锁定。对于聚集索引其仅对id等于5的索引加上Record Lock。而对于辅助索引其加上Next-Key Lock锁定了范围(1,3)特别需要注意的是InnoDB存储引擎还会对辅助索引下一个键值加上Gap Lock即范围(3.6)的锁。所以如果在新session中执行如下语句都会报错[Err] 1205 - Lock wait timeout exceeded; try restarting transactionselect * from T where id 5 lock in share MODE -- 不能执行因为事务A已经给id5的值加上了X锁执行会被阻塞INSERT INTO T SELECT 4,2 -- 不能执行辅助索引的值为2在(1,3)的范围内执行阻塞INSERT INTO T SELECT 6,5 -- 不能执行gap锁会锁住(3,6)的范围执行阻塞此时想象一下事务A锁定了f_id 5 的记录 正常会有个gap lock锁住(5,6)那么如果没有(5,6)的gap锁那么用户可以插入索引 f_id 为5的记录这样事务A再次查询就会返回一个不同的记录也就导致了幻读的产生。同理如果我们事务A执行的是select * from T where f_id 10 FOR UPDATE,在表里查不到数据但是基于Next-Key Lock会锁住(8∞)我们执行INSERT INTO T SELECT 6,11是无法插入成功的这就从根本上解决了幻读问题。总结以上就是这篇文章的全部内容了希望本文的内容对大家的学习或者工作具有一定的参考学习价值谢谢大家对脚本之家的支持。