时间：2021-07-01 10:21:17 帮助过：50人阅读
如果发现锁争用比较严重，如InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比较高，还可以通过设置InnoDB Monitors来进一步观察发生锁冲突的表、数据行等，并分析锁争用的原因。
可以用下面的语句来进行查看：
mysql> Show engine innodb status\G; *************************** 1. row *************************** Type: InnoDB Name: Status: … … ------------ TRANSACTIONS ------------ Trx id counter 0 117472192 Purge done for trx‘s n:o < 0 117472190 undo n:o < 0 0 History list length 17
在SHOW INNODB STATUS的显示内容中，会有详细的当前锁等待的信息，包括表名、锁类型、锁定记录的情况等，便于进行进一步的分析和问题的确定。打开监视器以后，默认 情况下每15秒会向日志中记录监控的内容，如果长时间打开会导致.err文件变得非常的巨大，所以用户在确认问题原因之后，要记得删除监控表以关闭监视 器，或者通过使用"--console"选项来启动服务器以关闭写日志文件。
1.行锁和表锁
在mysql 的 InnoDB引擎支持行锁，与Oracle不同，mysql的行锁是通过索引加载的，即是行锁是加在索引响应的行上的，要是对应的SQL语句没有走索引，则会全表扫描，
行锁则无法实现，取而代之的是表锁。
表锁：不会出现死锁，发生锁冲突几率高，并发低。
行锁：会出现死锁，发生锁冲突几率低，并发高。
锁冲突：例如说事务A将某几行上锁后，事务B又对其上锁，锁不能共存否则会出现锁冲突。（但是共享锁可以共存，共享锁和排它锁不能共存，排它锁和排他锁也不可以）
死锁：例如说两个事务，事务A锁住了1~5行，同时事务B锁住了6~10行，此时事务A请求锁住6~10行，就会阻塞直到事务B施放6~10行的锁，而随后事务B又请求锁住1~5行，事务B也阻塞直到事务A释放1~5行的锁。死锁发生时，会产生Deadlock错误。
锁是对表操作的，所以自然锁住全表的表锁就不会出现死锁。
2.行锁的类型
行锁分 共享锁 和 排它锁。
共享锁又称：读锁。当一个事务对某几行上读锁时，允许其他事务对这几行进行读操作，但不允许其进行写操作，也不允许其他事务给这几行上排它锁，但允许上读锁。
排它锁又称：写锁。当一个事务对某几个上写锁时，不允许其他事务写，但允许读。更不允许其他事务给这几行上任何锁。包括写锁。
上共享锁的写法：lock in share mode
例如： select math from zje where math>60 lock in share mode；
上排它锁的写法：for update
例如：select math from zje where math >60 for update；
3.行锁的实现
注意几点：
1.行锁必须有索引才能实现，否则会自动锁全表，那么就不是行锁了。
2.两个事务不能锁同一个索引，例如：
# 事务A先执行： select math from zje where math>60 for update; # 事务B再执行： select math from zje where math<60 for update； # 这样的话，事务B是会阻塞的。如果事务B把 math索引换成其他索引就不会阻塞， # 但注意，换成其他索引锁住的行不能和math索引锁住的行有重复。
3.insert ，delete ， update在事务中都会自动默认加上排它锁。
实现：
| 会话1： begin； select math from zje where math>60 for update； |
会话2： begin； update zje set math=99 where math=68； 阻塞........... |
会话相当与用户
如上，会话1先把zje表中math>60的行上排它锁。然后会话2试图把math=68的行进行修改，math=68处于math>60中，所以是已经被锁的，会话2进行操作时，
就会阻塞，等待会话1把锁释放。当commit时或者程序结束时，会释放锁。
由于InnoDB预设是Row-Level Lock，所以只有「明确」的指定主键，MySQL才会执行Row lock (只锁住被选取的资料例) ，否则MySQL将会执行Table Lock (将整个资料表单给锁住)。 举个例子: 假设有个表单products ，里面有id跟name二个栏位，id是主键。 例1: (明确指定主键，并且有此笔资料，row lock) SELECT * FROM products WHERE id=‘3‘ FOR UPDATE; SELECT * FROM products WHERE id=‘3‘ and type=1 FOR UPDATE; 例2: (明确指定主键，若查无此笔资料，无lock) SELECT * FROM products WHERE id=‘-1‘ FOR UPDATE; 例2: (无主键，table lock) SELECT * FROM products WHERE name=‘Mouse‘ FOR UPDATE; 例3: (主键不明确，table lock) SELECT * FROM products WHERE id<>‘3‘ FOR UPDATE; 例4: (主键不明确，table lock) SELECT * FROM products WHERE id LIKE ‘3‘ FOR UPDATE; 注1: FOR UPDATE仅适用于InnoDB，且必须在交易区块(BEGIN/COMMIT)中才能生效。 假设kid 是表table 的 一个索引字段 且值不唯一 1.如果kid 有多个值为12的记录那么： update table set name=’feie’ where kid=12; 会锁表 2.如果kid有唯一的值为1的记录那么： update table set name=’feie’ where kid=1; 不会锁表 总结：用索引字段做为条件进行修改时， 是否表锁的取决于这个索引字段能否确定记录唯一， 当索引值对应记录不唯一，会进行锁表，相反则行锁。 如果有两个delete kid1 与 kid2是索引字段 语句1 delete from table where kid1=1 and kid2=2; 语句2 delete from table where kid1=1 and kid2=3; 这样的两个delete 是不会锁表的 语句1 delete from table where kid1=1 and kid2=2; 语句2 delete from table where kid1=1 ; 这样的两个delete 会锁表 总结：同一个表，如果进行删除操作时，尽量让删除条件统一，否则会相互影响造成锁表
行级锁定不是MySQL自己实现的锁定方式，而是由其他存储引擎自己所实现的，如广为大家所知的InnoDB存储引擎，以及MySQL的分布式存储引擎NDBCluster等都是实现了行级锁定。考虑到行级锁定君由各个存储引擎自行实现，而且具体实现也各有差别，而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎，所以这里我们就主要分析一下InnoDB的锁定特性。
1.InnoDB锁定模式及实现机制
考虑到行级锁定君由各个存储引擎自行实现，而且具体实现也各有差别，而InnoDB是目前事务型存储引擎中使用最为广泛的存储引擎，所以这里我们就主要分析一下InnoDB的锁定特性。
总的来说，InnoDB的锁定机制和Oracle数据库有不少相似之处。InnoDB的行级锁定同样分为两种类型，共享锁和排他锁，而在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB也同样使用了意向锁（表级锁定）的概念，也就有了意向共享锁和意向排他锁这两种。
当一个事务需要给自己需要的某个资源加锁的时候，如果遇到一个共享锁正锁定着自己需要的资源的时候，自己可以再加一个共享锁，不过不能加排他锁。但是，如果遇到自己需要锁定的资源已经被一个排他锁占有之后，则只能等待该锁定释放资源之后自己才能获取锁定资源并添加自己的锁定。而意向锁的作用就是当一个事务在需要获取资源锁定的时候，如果遇到自己需要的资源已经被排他锁占用的时候，该事务可以需要锁定行的表上面添加一个合适的意向锁。如果自己需要一个共享锁，那么就在表上面添加一个意向共享锁。而如果自己需要的是某行（或者某些行）上面添加一个排他锁的话，则先在表上面添加一个意向排他锁。意向共享锁可以同时并存多个，但是意向排他锁同时只能有一个存在。所以，可以说InnoDB的锁定模式实际上可以分为四种：共享锁（S），排他锁（X），意向共享锁（IS）和意向排他锁（IX），我们可以通过以下表格来总结上面这四种所的共存逻辑关系：
如果一个事务请求的锁模式与当前的锁兼容，InnoDB就将请求的锁授予该事务；反之，如果两者不兼容，该事务就要等待锁释放。
意向锁是InnoDB自动加的，不需用户干预。对于UPDATE、DELETE和INSERT语句，InnoDB会自动给涉及数据集加排他锁（X)；对于普通SELECT语句，InnoDB不会加任何锁；