库存=10
事务并发带来的问题
悲观锁
持久性
锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁
每个事务和事务之间都是互不影响的
从对数据操作的粒度
并发
不可重复读
行锁
读锁
如何解决事务并发问题呢？
解决可重复读隔离级别下的幻读问题
锁优化建议尽可能让所有数据检索都通过索引来完成避免无索引行锁升级为表锁合理设计索引尽量缩小锁的范围尽可能减少检索条件范围避免间隙锁尽量控制事务大小减少锁定资源量和时间长度涉及事务加锁的sql尽量放在事务最后执行尽可能低级别事务隔离
无索引行锁会升级为表锁
事务C
事务隔离级别机制
一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读”
每次操作锁住一行数据。优点：锁定粒度最小，发生锁冲突的概率最低，并发最高。缺点：开销大，加锁慢；会出现死锁；
脏写
针对同一份数据，多个读操作可以同时进行而不会互相影响
一个更新写操作，一个查询读操作事务A读取到了事务B已经修改但是没有提交的数据，而且还在这个数据基础上进行进一步操作，此时，事务B回滚，那么事务A的数据将是无效数据，不符合一致性
表锁
从性能上
可重复度解决了读已提交隔离级别的不可重复读问题读已提交解决了读未提交隔离级别的脏读问题但是三个隔离级别都存在幻读问题，然而可串行化解决了所有问题，事务串行，但这种和事务并发相冲突，加了锁
优点：每次操作锁住整张表。开销小，加锁快；不会出现死锁；缺点：锁定粒度大，发生锁冲突的概率最高，并发度最低；使用场景：一般用在整表数据迁移的场景
当前写操作没有完成前，它会阻断其他写锁和读锁
乐观锁
比如两个事务都是更新同一条数据，由于每个事务不知道另外一个事务的存在，最终导致丢失更新问题：两个更新操作，最后的更新覆盖了由其他事务所做的更新font color=\"#000000\" style=\"font-weight: bold;\
事务的特性
原子性
锁是计算机协调多个进程或线程并发访问某一资源的机制
数据库中的数据一旦执行完成，不会再变更
一致性
矛盾
方法中的数据操作都执行成功才可以
Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别
事务A内部的相同查询语句在不同时刻查出了不同的结果，不符合隔离性
锁
间隙锁
幻读
session1执行：update account set balance=800 where name='lilei';session2对该表任一行操作都会阻塞住InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁。
事务A读取了事务B提交的新增的数据，不符合隔离性
脏读
查看当前数据库的事务隔离级别:showvariableslike'tx_isolation';设置事务隔离级别：settx_isolation='REPEATABLE-READ';
写锁
事务A
方法中的操作要么都成功，要么只要有一个失败，都失败
MVCC解决了可重复读的幻读问题，可以不加锁就满足事务的隔离性，而可串行化则是通过加锁来实现隔离性
事务B
Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一下，但是在整体并发处理能力方面要远远优于MYISAM的表级锁定的。当系统并发量高的时候，Innodb的整体性能和MYISAM相比就会有比较明显的优势了。但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MYISAM高，甚至可能会更差
隔离性
从对数据库操作的类型
串行
