事务的四大特性 - ACID
原子性（Atomicity） - 事务中的一组操作是不可分割的一个整体，要么一起成功，要么一起失败。
一致性（Consistency） - 事务前后 无论事务是否成功 数据库应该都保持一个完整性的状态,
数据库中数据完整性:数据库中数据 是业务完整 且约束完整的
- 业务完整: 事务的所有操作之前,A账户+B账户是2000元,那么事务操作之后,A账户+B账户还应该是2000元
- 约束完整: 事务的所有操作结束后,不会破坏之前的约束
隔离性（Isolation） - 多个并发事务之间应该互相隔离 互不影响
持久性（Durability） - 一个事务成功 对数据库产生的影响是永久性的 无论发生什么情况 这种影响都不会被取消
隔离性的问题
加锁 - 同一时间内只能有一个人操作数据 - 完美的保证隔离性 - 但是这样一来数据库就相当于工作在单线程的状态下 同一时间只能有一个事务操作 并发的效率非常低下
而现实生活中 并不是所有的场景下 都需要那么严格的事务隔离 在不同的业务场景下 对隔离性的要求是不同的
所以数据库的设计者 在设计隔离性时 并没有 将隔离性写死 而是提供了不同的选项 数据库的使用者可以在使用数据时 根据自身需求 选择对应的选项 来得到 相应的 隔离能力和性能
通过这些选项 数据库使用者 可以在数据库 隔离能力 和性能间 做一个权衡 从而在保证需要的隔离性的基础上 得到尽量好的 性能。
四大隔离级别
Read uncommitted
数据库不保证任何事务特性 可能出现脏读 不可重复读 虚读(幻读) 问题
脏读:一个事务读取到了另一个事务未提交的数据
Read committed
保证部分隔离 可以防止脏读问题 但是具有不可重复读 和 虚读(幻读)问题
不可重复读：一个事务读取到另一个事务已经提交的数据
Repeatable read
保证部分隔离 可以防止脏读 不可重复读问题 但是具有虚读(幻读)问题
虚读(幻读)：一个事务读取全表数据时 读取到另一个事务向表中新增、删除操作提交的结果
**虚读(幻读)问题 有可能出现 有可能不出现 概率非常低
Serializable
保证完全隔离 可以防止脏读 不可重复读 虚读(幻读)问题
本质上是靠锁来实现的
查看数据库隔离级别：
select @@tx_isolation;
设置数据库的隔离级别:
set [session/global] transaction isolation level xxxxxx;
global设置的是数据库服务器默认响应连接时使用的数据库隔离级别
session设置的是当前会话使用的数据库隔离级别
从安全性说：
Serializable > Repeatable read > Read committed > Read uncommitted
从效率说：
Read uncommitted >Read committed > Repeatable read > Serializable
mysql的默认隔离级别时 Repeatable read
数据库中的锁机制
数据库中是有锁的 但是锁 如果控制不好 对效率影响非常大 所以数据库设计者 对锁做了特别的设计：
两个查询 --> 没有必要互斥
两个修改 --> 必须互斥
一个查询 另一个 修改 --> 具体看情况 Serializable隔离级别下需要排斥 其他隔离级别不需要
共享锁
共享锁和共享锁可以共存 共享锁和排他锁不能共存
在非Serializable级别中查询不加任何锁 在Seralizable级别中查询加共享锁
排他锁
排他锁和任何锁都不能共存
在任意隔离级别下做增删改都加排他锁
死锁：
当两边都时Serializable隔离级别时
两边都先进行查询 再尝试进行修改 则互相等待对方释放共享锁 都无法接着执行 造成了死锁
死锁的解决有两种办法：避免死锁 解决死锁
mysql没有避免死锁 尝试检测死锁 发现死锁后 错误退出一方 执行另一方来解决了死锁。
悲观锁
悲观锁悲观的认为 每次查询都会造成更新丢失 所以在查询时 手动添加排它锁 排斥 查询 从而解决更新丢失问题
select * from xxx for update;#for update在查询时手动增加了排他锁
乐观锁
乐观锁乐观的认为 每次查询都不会造成更新丢失 在修改时 检测更新丢失的发生来进行纠正
悲观锁 和 乐观锁 都不是数据库中真正存在的锁 而是两种解决方案的名字
如果 查询多 而 更新少 用 乐观锁
如果 更新多 而 查询少 用 悲观锁
