Mysql InnoDB引擎的读锁
如果,在一个相同的事务中,你查询数据,然后插入/更新与此数据相关的数据,那个通常的SELECT语句不会给我们足够的保护.因为在我们当前事务的SELECT和UPDATE之间的时间段内,其他的事务可能会更新/删除我们刚刚读取到的行.而我们根本不会察觉.
InnoDB支持两种类型的读锁,可以给我们提供足够的安全.
1.SELECT ... LOCK IN SHARE MODE
这是共享锁，在读取的任何数据上设定一个共享模式的锁.其他事务可以读取这些数据.但是不能修改这些数据,除非我们设定锁的事务提交了.如果我们查询的数据正被其他事务修改,而且这些事务还没有提交,那么我们的查询会一直等待,直到这些事务提交,然后我们的查询就使用这些最新的数据.
注意:要想正确使用SELECT ... FOR UPDATE/SELECT ... LOCK IN SHARE MODE,必须关闭自动提交事务(set autocommit = 0),或者手动开启一个事务(begin/start transaction)，如果不开启事务，那些查询到的数据不会被加锁
2.SELECT ..... FOR UPDATE;
这是独占锁，会阻塞其他尝试修改的事务、使用SELECT....LOCK IN SHARE MODE的事务和一些事务隔离级别的事务（如FOR UPDATE）。
举例SELECT...FOR UPDATE,此方法要读取最新的结果
第一种情况,事务1开启事务并查询某条记录接着然后执行随后的动作,
事务1开启事务并查询一条记录
注意事务1并没有提交,此时事务2企图UPDATE此条记录
然而由于事务1还没有提交,事务2的UPDATE要等待,此刻用事务1再次查询此条记录,看记录有没有被改
上图可以发现,password并没有变
然后,事务1等了一会儿,终于提交了
这时候去看事务2,由于事务1commit后释放了锁，事务2就得到了锁，立刻返回了结果:
然后我再查询此条记录,发现终于更新为333了
在业务场景中，如果两个事务都使用lock in share mode，然后进行更新操作。如两个事务都获取了共享锁，在释放锁（commit或者roll back）之前都去执行update，由于update操作需要等待对方释放锁，就造成了死锁（deadlock），这是业务不允许的，所以一般使用FOR UPDATE让事务获取独占锁，完成事务后，才允许其他事务获取锁。
注意:
1.如果开启了事务1,在事务1的过程中，事务1执行SELECT（尚未提交）,事务2修改了数据并提交,此时，就算事务1再次执行SELECT,事务1也不会查到事务2所做的改动。除非重新开启事务。
2.加共享/独占锁的前提是：其他事务已经释放了独占锁
3. 关于 AUTOCOMMIT
因为涉及到事务，所以InnoDB才有自动提交这一说。虽然Myisam引擎中使用SET AUTOCOMMIT不会报错,但是由于没有事务功能，使用这条语句无效，没意义。
在InnoDB中,所有的用户行为都是在事务中发生,如果自动提交允许,每个SQL语句在它自己上形成一个单独的事务,mysql总是带着允许自动提交来开始一个新的连接.
但是,如果自动提交模式被用"SET AUTOCOMMIT = 0"关闭了,那么我们可以认为一个用户总是有一个事务在开着.
"COMMIT"或"ROLLBACK"语句结束当前事务并且开始新的事务,一个"COMMIT"语句意味着在当前事务中做的改变被生成永久的,并变成其他用户可见的.而一个"ROLLBACK"则是撤销所有当前事务做的修改.
