在日常操作中，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。然后更新时将读取的版本号作为条件，如果有其它事物更新了，那么必然会导致版本号变化，因为本次更新不会成功。这种机制最大程度的保证了并发。