MySQL：MySQL锁机制
目录
1、锁的定义
锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
2、锁的生活案例
3、锁的分类
3.1 从对数据操作的类型(读/写)来看
（1）读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响。
（2）写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和读锁。
3.2 从对数据操作的粒度(表/行)来看
（1）表锁（2）行锁
【 为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取、检查、释放锁等动作），因此，数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度（Lock granularity）”的概念。
一种提高共享资源并发发性的方式是 让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。】
4、三锁
4.1 表锁（偏读）
（1）特点
偏向MyISAM存储引擎，开销小，加锁快；无死锁；锁定粒度大，发生锁冲突的概率最高,并发度最低。
（2）案例分析：MyISAM存储引擎
（2.1）建表SQL
-- 【表级锁分析--建表SQL】
create table mylock(
id int not null primary key auto_increment,
name varchar(20)
)engine myisam;
insert into mylock(name) values('a');
insert into mylock(name) values('b');
insert into mylock(name) values('c');
insert into mylock(name) values('d');
insert into mylock(name) values('e');
select * from mylock;
--【手动增加表锁】
lock table 表名字1 read(write)，表名字2 read(write)，其它;
--【查看表上加过的锁】
show open tables;
--【释放表锁】
unlock tables;
（2.2）加读锁（读阻塞写的例子）
（2.3）加写锁
（3）案例结论（掌握）
（1）MyISAM存储引擎，在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。
（2）MySQL的表级锁有两种模式：表共享读锁（Table Read Lock）。表独占写锁（Table Write Lock）。
（3）结论：结合上表，所以对MyISAM存储引擎的表进行操作，会有以下情况：
1）对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。
2）对MyISAM表的写操作（加写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。
简而言之就是：读锁会阻塞写，但是不会堵塞读，而写锁则会把读和写都堵塞。
（4）表锁分析
-- 【手动增加表锁】
lock table 表名字1 read(write)，表名字2 read(write)，其它;
lock table mylock read,Test write;
-- 【查看哪些表上被加锁了】
show open tables;
-- 【释放表锁】
unlock tables;
-- 查看状态变量 Table_locks_immediate和Table_locks_waited
show status like "table%";
4.2 行锁（偏写）
（1）特点
1）偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
2）InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁。
（2）由于行锁支持事务，复习老知识：
（2.1）事务（Transaction）及其ACID属性
事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。
原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
一致性（Consistent）：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
隔离性（Isolation）：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
持久性（Durable）：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。
（2.2）并发事务带来的4个问题
相对于串行处理来说，并发事务处理能够大大增加数据库资源的利用率，提高数据库系统的事务吞吐量，从而可以支持更多的用户。但并发事务处理也会因隔离级别不同带来一些如下问题：
1）更新丢失(Lost Update)，也可以理解为版本覆盖
当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题：最后的更新覆盖了由其他事务所做的前期更新。
例如：两个程序员修改同一java文件。每个程序员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖前一个程序员所做的更改。
解决方法：如果在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。
2）脏读(Dirty Reads)
一个事务正在对一条记录做修改，在这个事务完成并提交之前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，那么第二个事务就会读取到这些“脏”数据，并据此做进一步的处理，此时就会产生未提交的数据依赖关系。这种现象被形象地叫做“脏读”。
一句话：事务A读取到了事务B 已修改但尚未提交的 数据，而且事务A还在这个数据的基础上做了操作。此时，如果B事务回滚，会导致事务A先前读取到的数据是无效的，是脏的，不符合一致性要求。
3）不可重复读(Non-Repeatable Reads)
一个事务在读取某些数据后的某个时间点，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或者某些记录已经被删除了，这种现象被称之为“不可重复读”。
在事务A内，读取了一些数据，在事务A还没有结束时，另一个事务B也访问了这些数据，并且对这些数据 做了update或者delete操作，且事务B提交了，紧接着，在事务A中，使用同样的查询SQL再次读取这些数据时，就会发现自己前后两次读到的数据不一样，这种现象就被称之为“不可重复读”。。
一句话：在一个事务范围内，两次相同的查询却返回了不同的数据（被其他事务在该事物前后两次读取数据之间做了 update or delete 操作），不符合隔离性。
4）幻读(Phantom Reads)
一个事务按相同的查询条件 重新读取以前检索过的数据，却发现其他事务 插入了 满足其查询条件的新数据，这种现象就称为“幻读”。
一句话：事务A读取到了事务B提交的新增数据，不符合隔离性（insert 操作）。
多说一句：幻读和脏读有点类似：脏读是事务B里面修改了数据；幻读是事务B里面新增了数据。
（3）使用事务的隔离级别来解决前面4个并发事务问题
事务的隔离性，要求系统必须保证事务不受其他并发执行的事务的影响。隔离级别规定了一个事务中所做的修改，在哪些事务内和事务间是可见的，哪些是不可见的，从而在一定程度上解决并发带来的数据问题。较低的隔离级别通常可以执行较高的并发，系统的开销也相对较低。为了解决“隔离”和“并发”的矛盾，MySQL定义了4个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同，应用根据自己的业务逻辑需求，通过选择不同隔离级别来平衡“隔离”和“并发”的矛盾。
隔离级别的简写：RU、RC、RR、S。
数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离 实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。
-- 查看当前数据库的默认事务隔离级别：
show variables like 'transaction_isolation';
show variables like 'tx_isolation'; -- (新版本已废弃)
mysql数据库在版本5.5之后使用InnoDB存储引擎。
（4）案例分析
（4.1）建表SQL
create table test_innodb_lock (a int(11),b varchar(16))engine=innodb;
insert into test_innodb_lock values(1,'b2');
insert into test_innodb_lock values(3,'3');
insert into test_innodb_lock values(4,'4000');
insert into test_innodb_lock values(5,'5000');
insert into test_innodb_lock values(6,'6000');
insert into test_innodb_lock values(7,'7000');
insert into test_innodb_lock values(8,'8000');
insert into test_innodb_lock values(9,'9000');
insert into test_innodb_lock values(1,'b1');
create index test_innodb_a_ind on test_innodb_lock(a);
create index test_innodb_lock_b_ind on test_innodb_lock(b);
select * from test_innodb_lock;
-- 默认是事务开关开启的，想要演示事务操作，需要手动先关闭一下
show variables like "%autocommit%";
set autocommit=0;
set autocommit=1;
（4.2）行锁定基本演示
发现：1号会话更新a=4的记录，成功，此时不提交时，然后 2号会话更新a=9的记录，发现也成功了，在会话1和会话2都提交后，再读取数据，发现a=4和a=9的记录都是最新的值。innoDB存储引擎在update时默认是行锁，只锁住一行记录，没锁住的记录其他事物仍然可以操作。
（4.3）无索引的行锁升级为表锁
mysql底层自动给字段b做了数据类型转换，把你写的整型 2000 转换为varchar类型 "2000"。
（4.4）间隙锁的危害
1）原始数据：
2）间隙锁的演示：先是操作session1会话，再试操作session2会话：
（4.5）如何锁定一行记录
（4.6）select 也可以加锁
1）共享锁 (Share Lock)：共享锁又称读锁，是读取操作时创建的锁。其他用户可以并发读取数据，但任何事务都不能对数据进行修改（修改操作默认会获取数据上的排他锁），直到已释放所有共享锁。如果事务T对数据A加上共享锁后，则其他事务只能对A再加共享锁，不能加排他锁；获取到共享锁的其他事务只能读数据，不能修改数据。
2）用法：显示加上读锁：select .. lock in share mode;
解释：在查询语句后面增加 LOCK IN SHARE MODE ，Mysql会对查询结果中的每行记录都加共享锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，可以成功申请共享锁，否则会被阻塞。其他线程也可以读取使用了共享锁的行，而且这些线程读取的是同一个版本的数据。
1）排他锁（eXclusive Lock）：排他锁又称写锁，如果事务T对数据A加上排他锁后，则其他事务不能再对A加任任何类型的锁。获取到排他锁的事务既能读数据，又能修改数据。
2）用法：显示加上写锁：select ... for update;
解释：在查询语句后面增加 FOR UPDATE ，Mysql会对查询结果中的每行都加排他锁，当没有其他线程对查询结果集中的任何一行使用排他锁时，则可以成功申请排他锁，否则会被阻塞。
（4.7）案列结论
Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。
但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差，比如行锁升级为表锁。
（4.8）如何分析行锁定
【如何分析行锁定】通过检查 InnoDB_row_lock 状态变量来分析系统上的行锁的争夺情况：
show status like 'innodb_row_lock%';
对各个状态量的说明如下：
1）Innodb_row_lock_current_waits：当前正在等待锁定的数量；
2）Innodb_row_lock_time：从系统启动到现在锁定总时间长度；
3）Innodb_row_lock_time_avg：每次等待所花平均时间；
4）Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
5）Innodb_row_lock_waits：系统启动后到现在总共等待的次数；
对于这5个状态变量，比较重要的主要是：
Innodb_row_lock_time_avg（等待平均时长），
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）这三项。
尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划：explain 、show profile 工具。
最后可以通过：SELECT * FROM information_schema.INNODB_TRX\G; 来查询正在被锁阻塞的sql语句。
select * from information_schema.INNODB_TRX\G;
（4.9）优化建议
1）尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
2）尽可能较少检索条件，避免间隙锁。
3）尽量控制事务大小，减少锁定资源量和时间长度。
4）锁住某行后，尽量不要去调别的行或表，赶紧处理被锁住的行然后释放掉锁。
5）涉及相同表的事务，对于调用表的顺序尽量保持一致。
6）在业务环境允许的情况下,尽可能低级别事务隔离。
4.3 页锁
开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。
了解一下即可。
99、番外篇
（1）原文请看这里：https://www.cnblogs.com/116970u/p/11006198.html
本文地址：https://blog.csdn.net/cmm0401/article/details/107299458