文中论述仅限于InnoDB，比较浅显，由于没有找到可靠可信的资料，可能存在错误。

首先回顾事务的分类，MySQL中，事务可以分为四个级别：详写版本

• 未提交读：Read uncommitted
  所有事务都可以看到其他未提交事务的执行结果。读取未提交的数据，也被称之为脏读（Dirty Read）。
• 已提交读：Read committed
  一个事务只能看见已经提交事务所做的改变，会出现不可重复读的问题。
• 可重复读：Repeatable read
  MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行，会出现幻读的问题。
• 可串行化：Serializable
  强制事务排序，使之不可能相互冲突，从而解决幻读问题。它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

在MySQL默认的隔离级别（可重复读）下，已经不存在脏读、不可重复读的问题，并且InnoDB存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了幻读的问题。

为什么还需要锁机制呢？

来看下面这种情况：当两个或多个事务选择同一行，然后基于最初选定的值并发更新该行时，由于每个事务都不知道其他事务的存在，就会发生更新丢失问题——最后的更新覆盖了其他事务所做的更新。
所以对于更新丢失这种问题，并不能单靠数据库事务控制器来解决，需要对要更新的数据加必要的锁来解决。

我们知道，InnoDB存储引擎的两个重要特性就是事务管理和行级锁。

所谓行级锁，顾名思义，就是对特定的一行或多行进行加锁。行级锁的锁定粒度最小（相对于表级锁和页级锁），发生锁冲突的概率最低，并发度也最高。但行锁可能会出现死锁。

死锁的例子：
比如事务A和事务B同时对记录a和记录b进行更新，事务A先对记录a更新（更新操作时InnoDB会对该行自动加锁），然后尝试对记录b更新，事务B先对记录b更新（假如与事务A更新记录a同时进行），然后尝试对记录a更新。此时，两个事务都等待对方释放锁，同时又持有对方需要的锁，则陷入死循环。

InnoDB实现了两种类型的行锁。

• 共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同记录集的排他锁。
• 排他锁（Ｘ）：允许获取排他锁的事务更新数据，阻止其他事务取得相同的记录集共享读锁和排他写锁。

为了允许行锁和表锁共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。

①意向共享锁（IS）：事务打算给记录行共享锁，事务在给一个记录行加共享锁前必须先取得该表的IS锁。

②意向排他锁（IX）：事务打算给记录行加排他锁，事务在给一个记录行加排他锁前必须先取得该表的IX锁。

意向锁是InnoDB自动加的，不需用户干预。

意向锁有啥用：解决表级锁和行级锁之间的冲突，比如事务A对表table1中的某条记录加了共享锁，让这一行只能读，不能写。此时，又有事务B申请table1的表锁。如果事务B申请成功，那么理论上它就能修改table1中的任意一行，这与A持有的行锁是冲突的。数据库需要避免这种冲突，就是说要让B的申请被阻塞，直到A释放了行锁。

那什么时候需要加锁呢？

对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及的记录集加排他锁；
对于普通SELECT语句，InnoDB不会任何锁，除非通过下述两种方式显式地加锁：
SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE：加共享锁
SELECT * FROM table_name WHERE ... FOR UPDATE：加排它锁

那只要是UPDATE、DELETE和INSERT语句，都一定是行锁吗？并不是！
InnoDB行锁是通过索引上的索引项来实现的：只有通过索引条件检索记录，InnoDB才会使用行级锁，否则，InnoDB将使用表锁！在实际应用中，要特别注意InnoDB行锁的这一特性，不然的话，可能导致大量的锁冲突（表锁粒度大，并发情况下极容易发生锁冲突），从而影响并发性能。

另外，InnoDB还有一种锁，叫间隙锁。
当我们用范围条件而不是相等条件检索数据来请求共享或排他锁时，InnoDB除了会给符合条件的已有记录的索引项加锁，还会对键值在条件范围内但并不存在的记录进行加锁，这种锁机制就是所谓的间隙锁（Next-Key锁）。

举例来说
假如emp表中只有101条记录，其empid的值分别是1,2,...,100,101，
SQL：SELECT * FROM emp WHERE empid > 100 FOR UPDATE
是一个范围条件的检索，InnoDB不仅会对符合条件的empid值为101的记录加锁，也会对empid大于101（这些记录并不存在）的“间隙”加锁。

InnoDB使用间隙锁的目的，一方面是为了防止幻读，以满足相关隔离级别的要求，对于上面的例子，如果不使用间隙锁，如果其他事务插入了empid大于100的任何记录，那么本事务如果再次执行上述语句，就会发生幻读；另一方面，是为了满足其恢复和复制的需要（TODO）。
很显然，在使用范围条件检索并锁定记录时，InnoDB这种加锁机制会阻塞符合条件范围内键值的并发插入，这往往会造成严重的锁等待。因此，在实际开发中，尤其是并发插入比较多的应用，我们要尽量优化业务逻辑，尽量使用相等条件来访问更新数据，避免使用范围条件。

参考

MySQL中的锁（表锁、行锁）
MySQL优化系列（八）--锁机制超详细解析（锁分类、事务并发、引擎并发控制）
MySQL innodb中各种SQL语句加锁分析
MySQL锁详解