概念
本事上是使用行级锁实现(排它锁,共享锁)
事物处理可以确保非事物性单元内的所有操作都成功完成,否则不会永远更新面向数据的资源。通过将这一组相关操作组合成为一个要么全部成功要么全部失败的的单元,可以简化错误恢复病史应用程序更加可靠。一个逻辑单元要成为事物,必须满足所谓的acid属性
属性
原子性
对于数据修改,要么全部都执行,要么全都不执行
隔离性
在所有的操作没有执行完毕之前,其他回话不能够看到中间改变的过程
案例:
我们打开俩个查询器,然后同时对一个表进行数据计算总值。可以看到起初的数据是一样的
一致性
事物发生前和发生后,根据数据的规则,总额应该匹配
持久性
事物一旦被提交,其结果就是永久性的,系统崩溃也不会影响
执行过程
因为MySQL5之后通常的默认存储引擎是InnoDB所以,以InnoDB为例讲解实现过程
MySQL在进行事务处理的时候使用的是日志现行的方式来保证事务可快速和持久运行的,也就是在写数据库前,需要先写日志。当开始一个事务时,会记录该事物的一个LSN日志序列号;当执行事务时,会往InnoDB_Log_Buffer 日志缓冲区里插入事务日志(redo log);当事务提交时,会将日志缓存区里的事务日志刷入磁盘。这个动作主要是由innodb_flush_log_at_trx_commit这个参数控制的。
发出commit动作时。已经说明过,commit发出后是否刷日志由变量 innodb_flush_log_at_trx_commit 控制。
每秒刷一次。这个刷日志的频率由变量 innodb_flush_log_at_timeout 值决定,默认是1秒。要注意,这个刷日志频率和commit动作无关。
当log buffer中已经使用的内存超过一半时。
当有checkpoint时,checkpoint在一定程度上代表了刷到磁盘时日志所处的LSN位置。
可以通过命令
show engine innodb status\G;
Log sequence number 8619676075 (表示当前的LSN日志序列号)
Log flushed up to 8619676075 (表示刷新到事物日志的LSN日志序列号)
Last checkpoint at 8619676075 (表示刷新到磁盘的LSN日志序列号)
除了记录事务日志意外,数据库还会记录一定量的撤销日志(undo log), undo与redo正好相反,在对数据进行修改时,由于某种原因失败了,或者人为执行了rollback回滚语句,就可以利用这些撤销日志将数据回滚到修改之前的样子。redo日志保存在ib_logfile0/1/2里,而undo日志保存在ibdata1里,在MySQL5.6里还可以把undo日志单拆分出去。
对于事务的建议
innodb存储引擎由于实现了行几所,颗粒更小,实现更复杂。但是innodb行锁在并发性能上远远要高于表锁页锁。在使用方面可以尽量做到以下几点;
控制事务大小,减少锁定的资源量和锁定时间长度。
人所有的数据检索都通过索引来完成,从而避免因为无法通过索引加锁而升级为表锁。
减少基于范围的数据检索过滤条件,避免因为间隙锁带来的负面影响而锁定了不该锁定的数据。
在业务条件允许下,尽量使用较低隔离级别的事务隔离。减少隔离级别带来的附加成本。
河里使用索引,让innodb在索引上面加锁的时候更加准确。
在应用中尽可能做到访问的顺序执行
如果容易死锁,就可以考虑使用表锁来减少死锁的概率