开发多用户、数据驱动的应用时，最大的难点是：一方面要最大程度的利用数据库的并发访问，另外一方面还要确保每个用户能以一致的方式读取和修改数据。

6.1 什么是锁

锁机制用于管理对共享资源的并发访问。提供数据的完整性和一致性。

6.2 InnoDB存储引擎中的锁

6.2.1 锁的类型

• 共享锁（S Lock），允许事务读一行数据

• 排他锁（X Lock），允许事务删除或更新一行数据

  
  锁兼容性

InnoDB为了支持在不同粒度（行级锁，表级锁）上进行加锁操作，支持一种额外的锁方式，意向锁。
其设计目的是为了在一个事务中揭示下一行奖杯请求的锁的类型。

• 意向共享锁（IS Lock），事务想要获得一个表中某几行的共享锁
• 意向排他锁（IX Lock），事务想要获得一个表中某几行的排他锁

6.2.2 一致性的非锁定读操作

一致性的非锁定读是指InnoDB存储引擎通过行多版本控制的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行删除更新，这时读取操作不会因此而会等待行上锁的释放，而是回去读取行的一个快照数据。
这个快照数据是通过Undo段来实现的，所以快照数据本身是没有额外的开销。快照数据也是不需要上锁的。
非锁定度大大提高了数据读取的并发性。同样的，不同隔离级别下可能导致不一样的结果

示例

Session A中最后一次查询

• 在Read Committed隔离级别下：

  
  Read Committed

• 在Repeatable Read隔离级别下：

  
  Repeatable Read

6.2.3 SELECT ... FOR UPDATE & SELECT ... LOCK IN SHARE MODE

• SELECT ... FOR UPDATE
  对读取的行加一个X锁，其他事务加任何锁都会被拒绝
• SELECT ... LOCK IN SHARE MODE
  对读取的行加一个S锁，其他事务可以加S锁，但是不能加X锁

6.24 自增长和锁

含有自增长列的表中会有一个自增长计数器，实现方式称做AUTO-INC Locking，这种锁是一种特殊的表锁机制，为了提高性能，锁不是在事务提交后释放，而是对自增长值插入语句完成后，立即释放。
当然，这依然会对并发性能产生影响，因为必须等待前一个插入操作完成。其次，对于INSERT ... SELECT 的大数据量插入，会影响插入性能，因为另一个事务中的插入会被阻塞。

留待感兴趣拓展：

• 自增长分类
• Innodb_autoinc_lock_mode （0，1，2）

MyISAM是表锁，所以是不用考虑并发插入问题
InnoDB中自增长值必须是索引（并不一定是聚集索引），且必须是索引的第一个列。

6.2.5 外键和锁

外键主要用于引用完整性（参照完整性）的约束检查。
但是对外键值的插入和更新，则不能非锁定读，因为可能会导致数据不一致

6.3 锁的算法

InnoDB中有3种行锁的算法设计

• Record Lock：单个行记录上的锁
• Gap Lock：间隙锁，锁定一个范围，但不包含记录本身。

• Next-Key Lock：Gap Lock + Record Lock，锁定一个 范围，并锁定记录本身

  
  行锁

6.4 锁问题

锁实现事务的隔离性要求，使得事务可以并发地工作。锁提高了并发，但是会带来问题。分如下三种

6.4.1 丢失更新

丢失更新

6.4.2 脏读

一个事务可以读到另一个事务未提交的数据，违反隔离性

脏读read uncommitted

6.4.3 不可重复读

不可重复读read committed

InnoDB默认为read repeatable
Oracle和Microsoft SQL Server 为 read committed

6.5 阻塞

InnoDB默认阻塞等待超时时不回滚

6.6 死锁

死锁

InnoDB不会回滚大部分的错误异常，但是死锁除外，死锁一定会马上回滚一个事务（开销较小？）。

6.7 锁升级

Lock Escalation 指将当前锁的粒度降低。如果数据库设计中认为锁是稀有资源，想避免锁的开销，那么锁升级可能会频繁出现。
目的就是降低开销，保护系统资源，防止系统使用太多的内存来维护锁，从一定程度上提高了效率。