在日常操作中,UPDATE、INSERT、DELETE InnoDB会自动给涉及的数据集加排他锁,一般的 SELECT 一般是不加任何锁的。我们可以使用以下方式显示的为 SELECT 加锁。
共享锁:
select * from table_name where id =10 lock in share mode;
排他锁:
select * from table_name where id=10 for update;
那么什么时候该用共享锁什么时候用排他锁呢?
一般来讲,共享锁主要用在需要数据依存关系时来确认某行记录是否存在,并确保没有人对这个记录进行UPDATE或者DELETE操作(包括加锁的事物也只能读)。简单说就是大家都可以读数据,但是无法修改(更新或者删除),因此我认为::共享锁也是悲观锁::的一种实现。
排他锁是与共享锁相对应,自身加排他锁的事物能够自己发起修改操作,其它事物无法再对该数据加共享或者排他锁。
这里需要注意上面说到的一点,由于InnoDB引擎是行锁,不管我们在这条数据上加了共享锁还是排他锁,简单的select语句依然可以使用的,因为默认在InnoDB中select是不加锁的。
这里还有一点,上图中我们写到一个 间隙锁,这是什么东西?比如:当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁(Next-Key锁)。它存在的主要目的有一个是为了解决幻读问题,因为RR作为InnoDB的默认事物隔离级别,是存在幻读问题的,而我们在实际操作中确没有出现,就是因为这里做了处理。
关于乐观锁是如何加锁的,这个不同系统有不同的实现,简单来说,对每一个数据维护一个版本号,每次读取时把版本号读取出来,更新时版本号+1。然后更新时将读取的版本号作为条件,如果有其它事物更新了,那么必然会导致版本号变化,因为本次更新不会成功。这种机制最大程度的保证了并发。