Question

mysql innodb存储引擎行级锁问题

一张表t 字段只有id
开启事务 select * from t where id <5 for update;//应该只锁id小于5的行记录吧？？
因为innodb是行锁
这时开启另外个事务
insert into t select 10;//此时却超时异常，为什么呢？上面那个事务不是只锁了id小于5的行记录吗

Answer 1

概念:
锁是用来管理对共享文件的并发访问。innodb会在行级别上对数据库上锁。不过innodb存储引擎会在数据库内部其他多个地方使用锁，从而允许对不同资源提供并发访问。例如操作缓冲池中的LRU列表，删除，添加，移动LRU列表中的元素，为了保证一致性，必须有锁的介入。MyISAM引擎是表锁，而InnoDB提供一致性的非锁定读、行级锁，且行级锁没有相关额外的开销。
锁
table-level locking（表级锁）
整个表被客户锁定。根据锁定的类型，其他客户不能向表中插入记录，甚至从中读数据也受到限制MyISAM、MEMORY默认锁级别，个别时候，InnoDB也会升级为表级锁
row-level locking（行级锁）
只有线程当前使用的行被锁定，其他行对于其他线程都是可用的InnoDB默认行级锁。是基于索引数据结构来实现的，而不是像ORACLE的锁，是基于block的。InnoDB也会升级为表级锁，全表/全索引更新，请求autoinc锁等
page-level locking（页级锁）
锁定表中某些行集合（称做页），被锁定的行只对锁定最初的线程是可行。如果另外一个线程想要向这些行写数据，它必须等到锁被释放。不过其他页的行仍然可以使用BDB默认页级锁
lock与latch
latch称为闩锁(轻量级的锁)，因为其要求锁定的时间必须非常短。若持续的时间长，则应用的性能会非常差。在InnoDB存储引擎中，又可以分为mutex(互斥量)和rwlock(读写锁)。其目的是用来保证并发线程操作临界资源的正确性，并且通常没有死锁检测的机制。latch可以通过命令show engine innodb mutex来进行查看。如图：

由上图可以看出列Type显示的总是InnoDB，列Name显示latch的信息以及所在源码的行数，列Status中显示的os_waits表示操作系统等待的次数。
lock的对象是事务，用来锁定的是数据库中的对象，如表、页、行。并且一般lock的对象仅在事务commit或者rollback后释放(不同事务隔离级别释放的时间可能不一样)。有死锁机制。二则的区别如下:

特点：
InnoDB是通过对索引上的索引项加锁来实现行锁。这种特点也就意味着，只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。
锁的类型:
有两种标准的行级锁:
共享锁(S lock):允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁.SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE
排它锁(X lock):允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他锁.SELECT * FROM table_name WHERE ... FOR UPDATE
InnoDB存储引擎支持意向锁且设计比较简练，分为两种内部使用的意向锁（Intention Locks），这两种意向锁都是表锁。(意向锁是InnoDB自动加的)
意向共享锁(IS):事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前必须先取得该表的IS锁.
意向独占锁(IX):事务打算给数据行加行排他锁，事务在给一个数据行加排他锁前必须先取得该表的IX锁.

追问

能用自己的话或者复制这个问题的概念吗

Answer 2

当 web 日志中出现行锁超时错误后，很多开发都会找我来排查问题，这里说下问题定位的难点！
1. MySQL 本身不会主动记录行锁等待的相关信息，所以无法有效的进行事后分析。
2. 锁争用原因有多种，很难在事后判断到底是哪一类问题场景，尤其是事后无法复现问题的时候。
3. 找到问题 SQL 后，开发无法有效从代码中挖掘出完整的事务，这也和公司框架-产品-项目的架构有关，需要靠 DBA 事后采集完整的事务 SQL 才可以进行分析。