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:: 分布式最终一致性，为什么可以不使用事务?