赞
踩
innodb_flush_log_at_trx_commit=1
(默认)的情况下,保证了事务的安全可靠隔离性
:由锁机制 or MVCC实现原子性、一致性、持久性
:由事务的redo日志和undo日志保证重做日志
,记录物理级别上的修改(在页上的修改)的日志,提供再写入操作,恢复提交事务修改页的操作,保证事务持久性
;主要保证数据可靠性回滚日志
,记录逻辑操作的日志(每个改动操作的逆过程),回滚到某一个特定版本,保证事务的原子性、一致性
;主要用于回滚和MVCCbuffer:在内存中,默认16M,内部的block块是512kb
file:在磁盘中
只要保证redo log从buffer持久化到file不出错,那么MySQL宕机也能恢复数据
默认值为1,虽然效率差,但安全。使用事务本来考虑的就是安全性优先
之后
都会产生一条redo log之前
回滚段roll back segment
决定的,默认是128*1024对于InnoDB来说,每一行都有3个隐藏列
这个序号是按顺序写入日志的,因此在回滚的时候直接倒叙回滚就好
4.3这种更新非主键是通过直接修改undo log指针指向来实现的。而如果修改主键id则需要利用deletemark
(一个软删除标志,=1则软删,真实的删除由purge线程
删除线程实现)
在RR(可重复读)的隔离级别下,insert操作只对本事务可见(RR级别的MVCC解决了幻读),因此insert操作的 undo log可以在commit之后直接删除
由于MVCC机制中的日志数组可能仍持有这条undo log记录,因此update操作commit后不能直接删除,而是存入undo log的一个链表中
问题一般是:脏读、不可重复读、幻读
SELECT @@transaction_isolation;
查看隔离级别RU:Read Uncommitted 读未提交,最低的隔离级别,任何情况都不加锁,在这个隔离级别下可能出现所有的问题
RC:Read Committed 读已提交,MVCC支持的最低隔离级别
RR:Read Repeatable 可重复读,在MVCC机制下可避免幻读
Serializable:串行化,最高的隔离级别,由加锁实现,最安全,性能最差
如果每条crud都加x锁,那么即便是不设置隔离级别为串行化,也是串行的
隔离性
是由锁实现的 (也可由MVCC)锁机制用于多个线程or进程并发访问某一个资源,保证数据的一致性和完整性。
锁机制保证了各个事务的隔离级别
锁机制一般不针对读-读,只针对读-写 、写-读 、写-写
共享锁(读锁)(S锁):SELECT ... LOCK IN SHARE MODE
或SELECT .. FOR SHARE
排他锁(写锁)(X锁):SELECT .. FOR UPDATE
读没什么好说的
由隐式锁
保护,保证新数据在commit之前不会被其他事务访问
从B+树找到该条记录的位置,获取这条记录的X锁,执行delete mark软删。真正的删除是purge线程删除
分为3种情况
没有死锁问题
表锁也有S锁和X锁,但是兼容性与行锁不同:具体体现在如下两点
语法演示:
begin;
lock tables xxx read; #也可以加write锁
show open tables where in_use > 0; #查看加锁的表
SELECT * FROM xxx ; # 正常可以查
UPDATE xxx SET s1 = 111 WHERE ... ;#阻塞,因为加了S表锁,所以同一事务也不能写当前表
unlock tables;#也可以直接commit; 都是释放表锁
如果事务想要获得数据表中某些记录的共享S锁,就需要在数据表上添加意向共享S锁。
如果事务想要获得数据表中某些记录的排他X锁,就需要在数据表上添加意向排他X锁。
如果主键设置的是auto_increment,那么就有这个自增锁,**当一个事务持有自增锁的时候,其他事务的insert语句都会被阻塞。**如果innoDB知道要插入多少条数据则不会上自增锁
insert...select
或 replace...select
或load data
或混合模式行锁在存储引擎层实现,粒度小,开销大,更容易出现死锁,并发度高
对于行锁的监控方法如下
这个就是可以自行添加,或在非RU级别下自动添加的锁,是狭义上的行锁
索引
,因为只有索引才能保证确定这个间隙锁的范围范围查询or查不存在的值
临键锁 = gap锁 + 记录锁
synchronized和ReentantLock
等等独占锁
都是悲观锁实现隐式锁是没有指令可以查看的,当且仅当产生锁等待的时候转为显示锁
上面能查看的锁都是显示锁
存储引擎层面:
业务设计层面:
数据库设计层面:
三个隐藏字段
、undo log
、readView
RR(REPEATABLE READ)
隔离级别下解决了幻读问题(如果没有MVCC机制则需要串行化or全加X锁才能解决幻读)ReadView
对于undo log的判断规则。只是后者不能解决幻读问题。MVCC保证的是读,锁保证的是写,因为写永远是针对最新的版本。快照读的前提是不能是串行化,串行化下快照读退化为当前读
每次事务修改这条记录,都会产生一个版本,版本中的隐藏列DB_ROLL_PTR指针又形成了undo log版本链
这里面包含的四个字段,都是事务id相关的,他们共同决定了在读取undo log版本链的时候究竟是读哪个版本的数据。并且跟隔离级别也有关系
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。