目录

表锁

读锁

写锁

总结

行锁

行锁可能出现的两个问题

无索引行锁变表锁

间隙锁

行锁的使用

总结

优化建议

---

表锁

偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。

手动增加表锁】
 lock table 表名字1 read(write)，表名字2 read(write)，其它;
【查看表上加过的锁】
  show open tables;

【释放表锁】
unlock tables;
 

读锁

写锁

总结

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。 
MySQL的表级锁有两种模式：
 表共享读锁（Table Read Lock）语句:lock table table_name read
 表独占写锁（Table Write Lock）语句:lock table table_name write

锁类型	自己可读	自己可写	他人可读	他人可写
读锁	是	否	是	否
写锁	是	是	否	否

结论：
 结合上表，所以对MyISAM表进行操作，会有以下情况： 
  1、对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。 
  2、对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
 简而言之，就是读锁会阻塞写，但是不会堵塞读。而写锁则会把读和写都堵塞

---

行锁

偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁

行锁可能出现的两个问题

无索引行锁变表锁

间隙锁

【什么是间隙锁】
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，
InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（GAP Lock）。
 
【危害】
因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害

行锁的使用

共享锁(Share Lock)
 
共享锁又称读锁，是读取操作创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（获取数据上的排他锁），直到已释放所有共享锁。
如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁。获准共享锁的事务只能读数据，不能修改数据。
 
用法
SELECT ... LOCK IN SHARE MODE;
 
在查询语句后面增加 LOCK IN SHARE MODE ，Mysql会对查询结果中的每行都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。其他线程也可以读取使用了共享锁的表（行？），而且这些线程读取的是同一个版本的数据。
 

---

排他锁（eXclusive Lock）
 
共享锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的封锁。获准排他锁的事务既能读数据，又能修改数据。
 
用法
 
SELECT ... FOR UPDATE;
 
       在查询语句后面增加 FOR UPDATE ，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请排他锁，否则会被阻塞。
 

---

 
 
【如何分析行锁定】
通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况
mysql>show status like 'innodb_row_lock%';

 
对各个状态量的说明如下：
 
Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time：从系统启动到现在锁定总时间长度；
Innodb_row_lock_time_avg：每次等待所花平均时间；
Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是
  Innodb_row_lock_time_avg（等待平均时长），
  Innodb_row_lock_waits（等待总次数）
  Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。
 
最后可以通过
SELECT * FROM information_schema.INNODB_TRX\G;
来查询正在被锁阻塞的sql语句。

总结

 
  Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。
 
  但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。

 

优化建议

1.尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。

2.尽可能较少检索条件，避免间隙锁.

3.尽量控制事务大小，减少锁定资源量和时间长度

4.锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。

5.涉及相同表的事务，对于调用表的顺序尽量保持一致。

6.在业务环境允许的情况下,尽可能低级别事务隔离