mysql隔离级别与锁，接口并发响应速度的关系(2)

innoDB默认隔离级别

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

两个事务同时更新一条数据

右图第二个事务的update增加行锁(表中id有索引), 在未提交之前，左图第一个事务update操作会进入阻塞状态, 左图中仍然可以进行select

右图第二个事务提交之后, 第一个事务会执行update并返回结果,但是还没有提交，  此时右图的查询结果是第二个事务提交的值

然后左图第一个事务也提交, 会覆盖右图第二个事务的值。左图操作的是右图变更前的数据，这个在并发时是不正常的

更新数据库的隔离级别为序列化

开启两个事务, 右图进行update操作, 左图事务的select操作会进入阻塞操作

右图提交之后, 左图事务select返回右图提交之后的结果

此时左图再update commit, 会覆盖右图的结果。左图操作的是右图变更后的数据, 这个在并发时是正常的.

总结: 

可重复读时，有幻读的问题, 使用行写锁 ，

序列化时,  select会阻塞，并发性能极低 == 没有并发, 使用行读锁  ，两个事务不能同时读， 并发极低 只能用在极度重要的场景

 https://tech.meituan.com/2014/08/20/innodb-lock.html

高并发更新覆盖的问题 应该在应用层去控制 悲观锁select for update 或者乐观锁@Version 

事务开启时DB会分配一个事务号，它是用来解决隔离级别的问题，但解决不了更新覆盖的问题，

https://docs.jboss.org/hibernate/core/3.6/reference/zh-CN/html/transactions.html#transactions-optimistic-manual 链接说明：事务开启时机@Transaction放在controller是可以的，可以减少数据库交互； 每个CRUD都开关事务会造成交互过多而性能低下

使用索引select for update时，会在行上加锁(具体哪种锁，读，写?), 悲观锁

不能使用索引时在表上加锁, 表锁也会极大的影响并发性能

 索引可以提高并发的原因:1.sql查询的数据量小，sql响应快 2.行锁，提高并发，不影响其他线程

TODO:: 分布式最终一致性，为什么可以不使用事务?