（1.15）mysql锁问题之InnoDB锁

关键词：innodb锁，mysql锁

概要：

1、事务的隔离级别

2、InnoDB锁争用

3、innodb锁

【3.1】innodb的行锁模式及加锁方法　

　其实，默认情况下，mysql 的 select 查询是不会加任何锁的，其他的CDU，都会先IX，再加上X锁

【3.2】innodb行锁实现方式

　　mysql的行锁是针对索引来加锁的~！

　　（1）在不通过索引条件查询时，走全表扫了，则innodb会锁定表中的所有记录

　　（2）mysql是通过索引加锁的，不是针对记录，如果索引值相同有多条记录，那么会被一并锁住。

　　（3）当表有多个索引的时候，不同的事务可以通过不同索引锁定不同的行，无论是使用主键索引、唯一索引或普通索引，innodb都会使用行锁对数据加锁。

　　（4）即使在条件中加了索引，但如果执行计划没有走索引，走的是全表扫，还是会全部上锁。

4、锁与恢复、复制的关系（基于binlog）

【4.1】binlog的恢复复制模式

【4.2】在做create table tab1 select * from source_tab 与 insert into tab1 select ...from source_tab时   会加共享锁。

　　    如果有范围性判断，该select操作还会加netx-key锁，以便保证数据恢复和复制的正确性

【4.3】innodb_locks_unsafe_for_binlog 设置为on（默认off） 导致主从不一致

innodb_locks_unsafe_for_binlog 设置为on 之后，【4.2】中事务图就不会加共享锁。但因为binlog是串行执行，可能会导致主从不一致。

【4.4】不同隔离级别下的锁

　　加共享锁： select  ........for update

　   加排它锁： select  ........LOCK IN SHARE MODE

5、什么时候使用表锁

6、MyISAM与innodb锁总结

　　

详细内容：

　　1、事务的隔离级别

　　

2、InnoDB锁争用

【2.1】行锁查看：show status like 'innodb_row_lock'

　　

　　如果锁争用比较高，比如 Innodb_row_lock_time 与 Innodb_row_lock_time_avg 比较高，可以查看【2.2】

【2.2】查看当前锁情况：select * from information_schema.innodb_locks \G

　　    查看当前锁等待情况：select * from information_schema.innodb_lock_waits \G

【2.3】使用innodb_monitors来查看innodb情况

　　show engine innodb status \G

　　

3、innodb锁

【3.1】innodb的行锁模式及加锁方法　

　其实，默认情况下，mysql 的 select 查询是不会加任何锁的，其他的CDU，都会先IX，再加上X锁

　　

　　　　

【3.2】innodb行锁实现方式

　　mysql的行锁是针对索引来加锁的~！

　　

　　（1）在不通过索引条件查询时，走全表扫了，则innodb会锁定表中的所有记录

　　　　

　　（2）mysql是通过索引加锁的，不是针对记录，如果索引值相同有多条记录，那么会被一并锁住。

　　　　比如id列有索引，name列没有索引。

　　　　

　　（3）当表有多个索引的时候，不同的事务可以通过不同索引锁定不同的行，无论是使用主键索引、唯一索引或普通索引，innodb都会使用行锁对数据加锁。

　　（4）即使在条件中加了索引，但如果执行计划没有走索引，走的是全表扫，还是会全部上锁。

【3.3】next-key锁

　　

　　

　　

4、锁与恢复、复制的关系（基于binlog）

【4.1】binlog的恢复复制模式

　　

【4.2】在做create table tab1 select * from source_tab 与 insert into tab1 select ...from source_tab时   会加共享锁。

　　    如果有范围性判断，该select操作还会加netx-key锁，以便保证数据恢复和复制的正确性

　　　　

　　　　

【4.3】innodb_locks_unsafe_for_binlog 设置为on（默认off） 导致主从不一致

innodb_locks_unsafe_for_binlog 设置为on 之后，【4.2】中事务图就不会加共享锁。

那么；

　　假如 session2先提交（也就是update先提交），session1后提交（也就是插入操作后提交）。

　　主库不会受到影响，但是从库会有影响，具体如下：

　　　　binlog是串行化执行的，谁先提交先执行谁。本来是要插入1的，因为并行update事务先提交，索引会先update，再插入，就导致主从数据不一致。最后插入的数据变成8了。

【4.4】innodb存储引擎中不同SQL在不同隔离级别下锁比较

　　

5、什么时候使用表锁

　　

6、MyISAM与innodb锁总结