MySQL锁机制

一、锁的定义

锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中,除传统的计算资源(如CPU、RAM、I/O等)的争用以外,数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题,锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说
,锁对数据库而言显得尤其重要,也更加复杂。
分类：
①从数据操作的类型分：分为读锁和写锁
读锁(共享锁):针对同一份数据,多个读操作可以同时进行而不会互相影响。
写锁(排它锁):当前写操作没有完成前,它会阻断其他写锁和读锁。
②从对数据操作的粒度分：分为表锁和行锁
表锁（偏读）
行锁（偏写）

1.表锁（偏读）

**特点：**偏向 MYISAM存储引擎,开销小,加锁快;无死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
如何加锁：

 #手动加锁
 LOCK TABLE 表名字 READ(WRITE),表名字2 READ(WRITE),其他;
 #查看表上加过的锁
 SHOW  OPEN TABLES
 
 #案例给`bigdata`上读锁给`books`上写锁
 LOCK TABLE `bigdata` READ,`books` WRITE;
#释放表
unlock tables;

(1)加读锁：

当前session可以查询该表记录，其他session也可以查询
当前session不能查询其他没有锁定的表，其他session可以查询或者更新未锁定的表
当前session中插入或者更新锁定的表都会提示错误，其他session插入或者更新锁定表会一直等待获得锁
当前session释放锁，其他session获得锁，插入操作完成

(2)加写锁

当前session对锁定表的查询、更新、插入操作都可以执行，其他session对锁定表的查询被阻塞，需要等待锁被释放

(3)结论

1、对 MYLSAM表的读操作(加读锁),不会阻塞其他进程对同一表的读请求,但会阻塞对同一表的写请求。只有当读锁释放后,
才会执行其它进程的写操作。
2、对 MYLSAM表的写操作(加写锁),会阻塞其他进程对同一表的读和写操作,只有当写锁释放后,才会执行其它进程的读写操
简而言之·，就是读锁会阻塞写，但是不会堵塞读，而写锁则会把读和写都堵塞

(4)如何分析表锁定

可以通过检查 table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定:
查询语句：

 SHOW STATUS LIKE 'table%';

这里有两个状态变量记录 MYSQL内部表级锁定的情况,两个变量说明如下
Table_locks_immediate:产生表级锁定的次数,表示可以立即获取锁的查询次数,每立即获取锁值加1
Table_locks_waited:出现表级锁定争用而发生等待的次数(不能立即获取锁的次数,每等待一次锁值加1),此值高则说明存在着较严重的表级锁争用情况.

此外, Myisam的读写锁调度是写优先,这也是 myisam不适合做写为主表的擎。因为写锁后,其他线程不能做任何操作,大量的
更新会使查询很难得到锁,从而造成永远阻塞。

2.行锁（偏写）

**特点：**偏向 InnoDB存储引擎,开销大，加锁慢，会出现死锁;锁定粒度小，发生锁冲突的概率最低，并发度最高。
如何使用：

#开启
set autocommit=0;
#提交
commit;

行锁基本演示：

(1)容易产生的问题

1.无索引行锁升级为表锁


2.间歇锁危害

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

(2)总结

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

(3)行锁分析

可以通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况:
查询语句：

 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(等待总次数)
Innodbrow_lock_time(等待总时长)这三项
尤其是当等待次数很高,而且每次等待时长也不小的时候,我们就需要分析系统中为什么会有如此多的等待,然后根据分析结果着手指定优化计划

（4）优化建议

• 尽可能让所有数据检索都通过索引来完成,避免无索引行锁升级为表锁。
• 合理设计索引,尽量缩小锁的范围
• 尽可能较少检索条件,避免间隙锁
• 尽量控制事务大小,减少锁定资源量和时间长度
• 尽可能低级别事务隔离