数据库的事务
0.转账案例 - 转账核心操作其实就是两条sql 这两条sql都执行成功才能正确转账 如果一条执行成功另一条执行失败 则 数据库中数据就出错了
create database day18; use day18; create table account ( id int primary key auto_increment, name varchar(255), money double ); insert into account values (null,'a',1000.0); insert into account values (null,'b',1000.0); update account set money = money-100 where name='a'; update account set money = money+100 where name='b'; select * from account;
在这个例子中 我们要保证 这两条sql要么一起成功 要么一起失败 不允许一部分成功一本分失败 这就要靠数据库的事务来实现了。
1.事务的概念
事务是逻辑上的一组操作 要求这一组操作要么同时完成 要么同时不完成。
2.事务操作
数据库默认就有事务，mysql中默认情况下一条语句独占一个事务。
也可以通过手动控制事务：
sql控制事务：
start transaction; #开启一个事务 这条语句之后的所有的sql都将处在同一个事务中。这些sql都不会立即起作用 - 没有改变底层真正的数据。
commit; #提交事务 这个事务中所有的sql对数据库的影响立即发生 - 真正改变底层数据。
rollback; #回滚事务 撤销这个事务中所有的操作可能的对数据库的影响。
start transaction;
update account set money = money-100 where name='a';
update account set money = money+100 where name='b';
commit;
start transaction;
update account set money = money-100 where name='a';
update account set money = money+100 where name='b';
rollback;
JDBC控制事务：
conn.setAutoCommit(false);#开启了事务，接下来在这个连接执行的所有sql都将处在同一个事务当中。
....
conn.commit();#提交事务，将这个连接上执行的事务提交，对数据库产生影响。
conn.rollback();#回滚事务，取消这个连接上执行的事务。
SavePoint sp = conn.setSavePoint();
conn.rollback(sp);
要注意，回滚到回滚点时，回滚点之前的代码仍然是未提交也未回滚的状态，如果希望对数据库产生影响仍然需要进行提交的操作。
3.事务的四大特性 - ACID
原子性 - 事务中的一组操作是不可分割的一个整体，要么一起成功，要么一起失败。
一致性 - 事务前后 无论事务是否成功 数据库应该都保持一个完整性的状态。
数据库中数据完整性:数据库中数据 是业务完整 且约束完整的。
隔离性 - 多个并发事务之间应该互相隔离 互不影响
持久性 - 一个事务成功 对数据库产生的影响是永久性的 无论发生什么情况 这种影响都不会被取消
4.隔离性的问题
加锁 - 同一时间内只能有一个人操作数据 - 完美的保证隔离性 - 但是这样一来数据库就相当于工作在单线程的状态下 同一时间只能有一个事务操作 并发的效率非常低下
而现实生活中 并不是所有的场景下 都需要那么严格的事务隔离 在不同的业务场景下 对隔离性的要求是不同的
所以数据库的设计者 在设计隔离性时 并没有 将隔离性写死 而是提供了不同的选项 数据库的使用者可以在使用数据时 根据自身需求 选择对应的选项 来得到 相应的 隔离能力和性能
通过这些选项 数据库使用者 可以在数据库 隔离能力 和性能间 做一个权衡 从而在保证需要的隔离性的基础上 得到尽量好的 性能。
5.四大隔离级别
Read uncommitted
Read committed
Repeatable read
Serializable
(1)Read uncoommitted
数据库不保证任何事务特性 可能出现脏读 不可重复读 虚读(幻读) 问题
脏读:一个事务读取到了另一个事务未提交的数据
a:
set session transaction isolation level read uncoommitted;
---------------
a: 1000
b: 1000
---------------
b:
start transaction;
update account set money = money - 100 where name = 'b';
update account set money = money + 100 where name = 'a';
a:
start transaction;
select * from account;
---------------
a: 1100
b: 900
---------------
commit;
b:
rollback;
a:
start transaction;
select * from account;
---------------
a: 1000
b: 1000
---------------
commit;
(2)Read committed
保证部分隔离 可以防止脏读问题 但是具有不可重复读 和 虚读(幻读)问题
不可重复读：一个事务读取到另一个事务已经提交的数据
a:
set session transaction isolation level read committed;
-------------------------
a 1000 1000 1000
-------------------------
b:
start transaction;
select 活期 from account where name = 'a'; -- 活期存款1000
select 定期 from account where name = 'a'; -- 定期存款1000
select 固定 from account where name = 'a'; -- 固定存款1000
-------------
a:
start transaction;
update account set money = money - 1000 where name = 'a';
commit;
-------------
select 活期 + 定期 + 固定 from account where name = 'a'; -- 总资产2000
(3)Repeatable read
保证部分隔离 可以防止脏读 不可重复读问题 但是具有虚读(幻读)问题
虚读(幻读)：一个事务读取全表数据时 读取到另一个事务向表中新增、删除操作提交的结果
**虚读(幻读)问题 有可能出现 有可能不出现 概率非常低
set session transaction isolation level Repeatable read;
-------------------------
a 1000
b 1000
-------------------------
c：
start transaction;
select count(*) from account; -- 2人
select sum(money) from account; -- 2000元
--------
d：
start transaction;
insert into account values(d 4000);
commit;
-------------------------
a 1000
b 1000
d 4000
-------------------------
--------
select avg(money) from account; -- 2000元
commit;
(4)Serializable
保证完全隔离 可以防止脏读 不可重复读 虚读(幻读)问题
本质上是靠锁来实现的
从安全性说：
Serializable > Repeatable read > Read committed > Read uncommitted
从效率说：
Read uncommitted >Read committed > Repeatable read > Serializable
真正在开发的过程中 应该根据自身的业务需求 选择一个 在能防止想要防止的隔离性问题的级别中 性能 最好的一个隔离级别
mysql的默认隔离级别时 Repeatable read
查看数据库隔离级别：
select @@tx_isolation;
设置数据库的隔离级别:
set [session/global] transaction isolation level xxxxxx;
6.数据库中的锁机制
数据库中是有锁的 但是锁 如果控制不好 对效率影响非常大 所以数据库设计者 对锁做了特别的设计：
两个查询 --> 没有必要互斥
两个修改 --> 必须互斥
一个查询 另一个 修改 --> 具体看情况 Serializable隔离级别下需要排斥 其他隔离级别不需要
共享锁
共享锁和共享锁可以共存 共享锁和排他锁不能共存
在非Serializable级别中查询不加任何锁 在Seralizable级别中查询加共享锁
排他锁
排他锁和任何锁都不能共存
在任意隔离级别下做增删改都加排他锁
操作和锁的关系
1. 非Serializable级别,查询不加任何锁
2. Serializable级别,查询加共享锁
3. 任意隔离级别下,增删改都加排他锁
a(Rep) b(Rep) 结果 原因
a查询 b查询 不互斥 都不加锁
a查询 b增删改 不互斥 a不加锁+b排他锁
a增删改 b查询 不互斥 a排他锁+b不加锁
a增删改 b增删改 互斥 a排他锁+b排他锁
a(Ser) b(Rep) 结果 原因
a查询 b查询 不互斥 a共享锁+b不加锁
a查询 b增删改 互斥 a共享锁+b排他锁
a增删改 b查询 不互斥 a排他锁+b不加锁
a增删改 b增删改 互斥 a排他锁+b排他锁
a(Ser) b(Ser) 结果 原因
a查询 b查询 不互斥 a共享锁+b共享锁
a查询 b增删改 互斥 a共享锁+b排他锁
a增删改 b查询 互斥 a排他锁+b共享锁
a增删改 b增删改 互斥 a排他锁+b排他锁
死锁：
当两边都时Serializable隔离级别时
两边都先进行查询 再尝试进行修改 则互相等待对方释放共享锁 都无法接着执行 造成了死锁
死锁的解决有两种办法：避免死锁 解决死锁
mysql没有避免死锁 尝试检测死锁 发现死锁后 错误退出一方 执行另一方来解决了死锁。
