一、Latch & Lock

在数据库中 Latch & Lock 都可以被称为锁，但两者有着截然不同的意义。

Latch 一般被称为闩锁(轻量级的锁)，锁定的时间很短，若持续的时间长，则应用的性能会非常差。

在 InnoDB 中 Latch 锁又可以分为 mutex (互斥量) 和 rwlock (读写锁)。其主要目的是用来保证并发线程操作临界资源的正确性，并且没有死锁检测机制。

## Latch 是一个非常透明的东西，一般除了非常底层的数据库人员很难看懂

## show engine innodb mutex;

Lock 的对象是事务，用来锁定的数据库中的对象，如表，页，行。一般 Lock 的对象仅在事务 commit 或rollback 后进行释放(不同事务隔离级别释放的时间可能不同)。Lock 与 Latch 不同的是 Lock 有死锁检测机制的。

二、InnoDB 存储引擎中的锁

一、InnoDB 存储引擎中的锁：

S 行级共享锁：允许事务读一行数据；lock in share mode。

X 行级排他锁 :  允许事务更新或删除一行数据；增删改产生排它锁，还有一个比较特殊 select ... for update。

IS : 意向锁

IX : 意向排他锁

AI : 自增锁，AI 自增锁 ，自增锁是用来做自增的并发控制的。

二、锁之间的兼容性

锁兼容(Lock Compatible)： 如果事务T1 获得行 r 的共享锁，那么另外的事务 T2 可以立即获得行 r 的共享锁，因为读取并没有改变行 r 的数据。

锁不兼容： 若有其他的事务 T3 想获得行 r 的排他锁，则必须等待事务 T1、T2 释放行 r 上的共享锁。

表 1-1 排它锁和共享锁的兼容性

从表1-1 可以看出 ，X锁与任何的锁都不兼容，而 S 锁仅和 S 锁兼容。S 锁 和 X 锁都是行锁 ，兼容是指对同一记录(row)锁的兼容情况。

意向锁： 用来实现多粒度级别的锁的。

揭示下一层级请求的锁类型。

IS ： 事务想要获得一张表中某几行的共享锁

IX ： 事务想要获得一张表中某几行的排它锁

InnoDB 中意向锁都是表锁(简单的这样理解下)

数据库总共有表锁，页锁，记录锁，但是在 MySQL 中只有表锁跟记录锁，意向锁都是加在表上的。

意向锁之间都是兼容的，用来揭示下一层级的锁。

表 1-2 InnoDB 存储引擎中锁的兼容性

三、查看锁对象内容

使用 show engine innodb status

(root@localhost) [(none)]> pager less

PAGER set to ‘less‘

(root@localhost) [(none)]>

(root@localhost) [(none)]> show engine innodb status \G

TRANSACTIONS

------------

如果想查看比较详细的锁的信息，可通过开启 innodb_status_output_locks

(root@localhost) [test]> set global innodb_status_output_locks=1;

Query OK,0 rows affected (0.00sec)

(root@localhost) [test]> show variables like ‘%innodb_status_output%‘;+----------------------------+-------+

| Variable_name | Value |

+----------------------------+-------+

| innodb_status_output | OFF |

| innodb_status_output_locks | ON |

+----------------------------+-------+

2 rows in set (0.00 sec)

如下是开启 innodb_status_output ，show engine innodb status 输出的详细信息：

找到 TRANSACTIONS , heap_no 2,3,4 表示的是插入的顺序，其中包含两个隐藏列， len 6 是指针列，len 7 是什么列来着忘了

在 show engine innodb status 中的 thread_id 对应的是 show processlist 中 processlist_id 。

这样看有点麻烦，可以借助 information_schema 中的几张表，innodb_trx，innodb_locks，innodb_lock_waits

在 5.7 版本中有一张 innodb_lock_waits

(root@localhost) [sys]> select * frominnodb_lock_waits\G*************************** 1. row ***************************wait_started:2019-02-28 16:26:18wait_age:00:00:18wait_age_secs:18locked_table: `test`.`lock_1`

locked_index:PRIMARYlocked_type: RECORD

waiting_trx_id:260217waiting_trx_started:2019-02-28 16:26:18waiting_trx_age:00:00:18waiting_trx_rows_locked:1waiting_trx_rows_modified:0waiting_pid:18waiting_query:update lock_1 set b=6 where a=4waiting_lock_id:260217:217:3:3waiting_lock_mode: X

blocking_trx_id:260213blocking_pid:19blocking_query:NULLblocking_lock_id:260213:217:3:3blocking_lock_mode: X

blocking_trx_started:2019-02-28 16:11:46blocking_trx_age:00:14:50blocking_trx_rows_locked:1blocking_trx_rows_modified:0sql_kill_blocking_query:KILL QUERY 19sql_kill_blocking_connection:KILL 19

1 row in set, 3 warnings (0.00 sec)

#　kill query ：表示杀掉查询，

#　kill 表示这个连接也杀掉

四、AI 自增锁

MySQL 的自增存在一个回溯问题，简单说 MySQL 的自增是不持久化的。当数据库被异常重启 可以通过 select max(auto_inc_col)from t for update;

重新获得表的自增起始id 值，这个可能会造成 id 冲突。

自增锁在提交完成之后就已经被释放了。所以自增锁持有的时间是SQL的执行时间。假如你插入的是一个大事务的话就会出现阻塞了。

而x,ix 等是需要commit 之后才能释放的。

设置 innodb_autoinc_lock_mode=2 // 每一条记录加锁释放，这个提高了并发能力，但是可能出现一条语句中的数据不连续了。