为了保证并发时数据的完整性以及正确性, 数据库中引入了事务的概念 , 意为在某一个功能单元 , 要么同时成功 , 要么同时失败 .
1.事务
1.1 数据库事务有四大特性:
1.1.1原子性(Atomicity):事务是数据库的逻辑工作单位,它对数据库的修改要么全部执行,要么全部不执行。
1.1.2 一致性(Consistemcy):事务执行前后,数据库的状态都满足所有的完整性约束。
1.1.3 隔离性(Isolation):并发执行的事务是隔离的,保证多个事务互不影响。如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。通过设置数据库的隔离级别,可以达到不同的隔离效果。
1.1.4 持久性(Durability):一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。
1.2 数据库事务有四大隔离级别:
MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ) ; oracel 默认级别是 读已提交;
· 未提交读(READUNCOMMITTED)。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读)。
· 提交读(READCOMMITTED)。本事务读取到的是最新的数据(其他事务提交后的)。问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读)。
· 可重复读(REPEATABLEREAD)。在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象(稍后解释)。
· 串行化(SERIALIZABLE)。读操作会隐式获取共享锁,可以保证不同事务间的互斥。
四个级别逐渐增强,每个级别解决一个问题。
可能产生的问题
. 脏读,最容易理解。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据。
· 不重复读。解决了脏读后,会遇到,同一个事务执行过程中,另外一个事务提交了新数据,因此本事务先后两次读到的数据结果会不一致。
· 幻读。解决了不重复读,保证了同一个事务里,查询的结果都是事务开始时的状态(一致性)。但是,如果另一个事务同时提交了新数据,本事务再更新时,就会“惊奇的”发现了这些新数据,貌似之前读到的数据是“鬼影”一样的幻觉。
隔离级别 | 脏读(Dirty Read) | 不可重复读(NonRepeatable Read) | 幻读(Phantom Read) |
---|---|---|---|
未提交读(Read uncommitted) | 可能 | 可能 | 可能 |
已提交读(Read committed) | 不可能 | 可能 | 可能 |
可重复读(Repeatable read) | 不可能 | 不可能 | 可能 |
可串行化(Serializable ) | 不可能 | 不可能 | 不可能 |
1.3 事务运行的三种模式
1.3.1 自动提交事务:默认事务管理模式。如果一个语句成功地完成,则提交该语句;如果遇到错误,则回滚该语句。
1.3.2 显式事务:以BEGIN TRANSACTION显式开始,以COMMIT或ROLLBACK显式结束。
1.3.3 隐性事务:当连接以此模式进行操作时,sql将在提交或回滚当前事务后自动启动新事务。无须描述事务的开始,只需提交或回滚每个事务。它生成连续的事务链。
1.4 数据库事务与事务日志
以mysql的innodb的事务为例,通过事务日志实现ACID特性。事务日志遵循WAL(Write-Ahead Logging 预写日志方式)协议。
以oracel为例: 查看数据库日志文件路径可用 SELECT * FROM V$logfile; 查看近期操作日志可用SELECT * FROM V$sql; 不过查出来的日志直接看看得不是很直观 , 可用oracel提供的LogMiner来查看分析后的日志.
数据库日志文件是非常重要的文件 , 如果不小心对数据库进行误删等操作 , 恢复时日志文件是很好的依据.
2. 锁
数据库事务底层的实现就是通过锁机制来实现的, 从大的分类上, 我们可以将锁分为乐观锁和悲观锁, 而悲观锁又可延伸出共享锁(读锁) 排他锁(写锁) 再细分一点 可以分为行锁 表锁 页锁
乐观锁不是数据库自带的,需要我们自己去实现。乐观锁是指操作数据库时(更新操作),想法很乐观,认为这次的操作不会导致冲突,在操作数据时,并不进行任何其他的特殊处理(也就是不加锁),而在进行更新后,再去判断是否有冲突了。
通常实现是这样的:在表中的数据进行操作时(更新),先给数据表加一个版本(version)字段,每操作一次,将那条记录的版本号加1。也就是先查询出那条记录,获取出version字段,如果要对那条记录进行操作(更新),则先判断此刻version的值是否与刚刚查询出来时的version的值相等,如果相等,则说明这段期间,没有其他程序对其进行操作,则可以执行更新,将version字段的值加1;如果更新时发现此刻的version值与刚刚获取出来的version的值不相等,则说明这段期间已经有其他程序对其进行操作了,则不进行更新操作。
共享锁【S锁】
又称读锁,若事务T对数据对象A加上S锁,则事务T可以读A但不能修改A,其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁。这保证了其他事务可以读A,但在T释放A上的S锁之前不能对A做任何修改。
排他锁【X锁】
又称写锁。若事务T对数据对象A加上X锁,事务T可以读A也可以修改A,其他事务不能再对A加任何锁,直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。
行锁,由字面意思理解,就是给某一行加上锁,也就是一条记录加上锁。
比如SELECT * from city where id = "1" lock in share mode;
由于对于city表中,id字段为主键,就也相当于索引。执行加锁时,会将id这个索引为1的记录加上锁,那么这个锁就是行锁。
表锁,和行锁相对应,给这个表加上锁。
mysql innodb事务死锁:
事务A需要先查询数据1,然后修改数据2;
事务B需要先查询数据2,然后修改数据1;
此时2个事务并发执行,由于mysql innodb的默认隔离级别是可重复读,读锁、写锁只能在事务结束才会释放。
事务A中需要等待事务B释放数据2的共享锁,才能执行对数据2添加排他锁;事务B需要等待事务A释放数据1的共享锁,才能执行对数据1添加排他锁。这样会就出现事务死锁
这种死锁在oracle中就不会出现,因为oracle的默认隔离级别是读已提交,共享锁在执行完查询之后就会释放,不会导致排他锁无法添加的问题。
如果大家在看博客时发现有说得不严谨的地方 , 欢迎回复交流.MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ)。
· 未提交读(READUNCOMMITTED)。另一个事务修改了数据,但尚未提交,而本事务中的SELECT会读到这些未被提交的数据(脏读)。
· 提交读(READCOMMITTED)。本事务读取到的是最新的数据(其他事务提交后的)。问题是,在同一个事务里,前后两次相同的SELECT会读到不同的结果(不重复读)。
· 可重复读(REPEATABLEREAD)。在同一个事务里,SELECT的结果是事务开始时时间点的状态,因此,同样的SELECT操作读到的结果会是一致的。但是,会有幻读现象(稍后解释)。
· 串行化(SERIALIZABLE)。读操作会隐式获取共享锁,可以保证不同事务间的互斥。
四个级别逐渐增强,每个级别解决一个问题。