mysql学习笔记-锁【1】- 数据库,表锁,行锁理论概述与实际操作

锁的分类

1.从对数据操作的类型(读\写)分

• 1.1 读锁(共享锁):针对同一份数据，多个读操作可以同时进行而不会互相影响。
• 1.2 写锁(排它锁):当前写操作没有完成前，它会阻断其他写锁和读锁。

2. 从对数据操作的粒度分

2.1 表锁（偏读）

特点

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

案例

# 建表语句
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');

手动增加表锁

lock table 表名字read(write),表名字2 read(write)其他
# 锁住当前表
lock table mylock read;
# 释放表锁
unlock tables;

查看当前被锁住的表

show open tables 

释放当前被锁住的表

unlock tables;

开始测试

# 添加读锁
lock table mylock read;
# 修改数据 
update mylock set name ='a2' where id = 1;
# 提示 1099-表“mylock”被读锁锁定，无法更新1099 - Table 'mylock' was locked with a READ lock and can't be updated
# 这时候这个库的其他表是不能 查询的，注意：只在当前session中限制
# 这是新开一个session2执行修改操作会被锁住
update mylock set name ='a3' where id =1;
# 这时候在session1中释放表锁 session2中的update操作就会执行成功
unlock tables

# 添加写锁
# 在session1添加写锁
lock table mylock write ;
# 这时候在session1中执行，是可以查出数据的
select * from mylock ;
+----+------+
| id | name |
+----+------+
|  1 | a3   |
|  2 | b    |
|  3 | c    |
|  4 | d    |
|  5 | e    |
+----+------+
# 这是在session1执行update语句 ->执行成功
update mylock set name='a4' where id =1;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# 这时候在session1中执行查询这个库当中的其他表-> 会被锁住
 select * from test03;
1100 - Table 'test03' was not locked with LOCK TABLES
# 这时候在session2中执行查询这个库当中的其他表-> 执行成功
select * from test03;
+----+----+----+----+----+----+
| id | c1 | c2 | c3 | C4 | c5 |
+----+----+----+----+----+----+
|  1 | a1 | a2 | a3 | a4 | a5 |
|  2 | b1 | b2 | b3 | b4 | b5 |
|  3 | c1 | c2 | c3 | c4 | c5 |
|  4 | d1 | d2 | d3 | d4 | d5 |
|  5 | e1 | e2 | e3 | e4 | e5 |
+----+----+----+----+----+----+
# 这时候 在session2中执行—>会被阻塞
select * from mylock;
# 这时候在session1中释放锁session2中就会立马被执行
unlock tables;

如何分析表锁定

#可以通过检查table_ locks_ _waited和table_ locks_ _immediate状态变量来分析系统上的表锁定:
 show status like "table%";
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| Table_locks_immediate      | 1046491 |
| Table_locks_waited         | 0       |
| Table_open_cache_hits      | 24      |
| Table_open_cache_misses    | 0       |
| Table_open_cache_overflows | 0       |
+----------------------------+---------+
# 这里有两个状态变量记录MySQL内部表级锁定的情况，两个变量说明如下:
#Table_ locks_ immediate: 产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1 ;
# Table_locks__waited:出现表级锁定争用而发生等待的次数(不能立即获取锁的次数，每等待一次锁值加1)，此值高则说明存在着较严重的表级锁争用情况;

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

总结

• MyISAM在执行查询语句(SELECT) 前，会自动给涉及的所有表加读锁，在执行增刪改操作前，会自动给涉及的表加写锁。
• MySQL的表级锁有两种模式:
  1. 表共享读锁(Table Read Lock)
  2. 表独占写锁(Table Write Lock)

锁类型	可否兼容	读锁	写锁
读锁	是	是	否
写锁	是	否	否

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

2.2 行锁

特点

• 偏向InnoDB存储引擎， 开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
• InnoDB与MyISAM的最大不同有两点:一是支持事务(TRANSACTION) ;二是采用了行级锁

简要说明事物

• 事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。
• I原子性(Atomicity) :事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
• 一致性(Consistent) :在事务开始和完成时，数据都必须保持一 致状态。这意味着所有相关的数据规则都必须应用于事务的修改
• ，以保持数据的完整性;事务结束时，所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。
• 隔离性(Isolation) :数据库系统提供一 定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处
• 理过程中的中间状态对外部是不可见的，反之亦然。
• 持久性(Durable) :事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

并发事物处理带来的问题

• 更新丢失(Lost Update)

  1. 当两个或多个事务选择同-行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问 题–最后的更新覆盖了由其他事务所做的更新。
  2. 例如，两个程序员修改同一java文件。每程序员独立地更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其
     更改副本的编辑人员覆盖前一个程序员所做的更改。
  3. 如果在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。

• 脏读(Dirty Reads)

  1. 一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态;这时，另一个事务也来读取同一
     条记录，如果不加控制，第二个事务读取了这些“脏”数据，并据此做进一 步的处理，就会产生未提交的数据依赖关系。这种现象
     被形象地叫做”脏读”。
  2. 一句话:事务A读取到了事务B已修改但尚未提交的的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合-致性要求。

• 不可重复读(Non-Repeatable Reads)

  1. 一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被刪除 了!这种现象就叫做“不可重复读”。
  2. 一句话:事务A读取到了事务B已经提交的修改数据，不符合隔离性

• 幻读(Phantom Reads)

  1. 一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为“幻读
  2. 一句话:事务A读取到了事务B体提交的新增数据，不符合隔离性。
  3. 多说一句:幻读和脏读有点类似，
     1. 脏读是事务B里面修改了数据，
     2. 幻读是事务B里面新增了数据。

事物隔离级别

• "脏读”.“不可重复读” 和“幻读”，
  ， 其实都是数据库读一 致性问题，必须由数据库提供- 定的事务隔离机制来解决。

读数据一致性及允许的并发副作用隔离级别	读数据一致性	脏读	不可重复读	幻读
未提交读( Read uncommitted )	最低级别,只能保证不读取物理上损坏的数据	是	是	是
已提交度( Read committed )	语句级	否	是	是
可重复读( Repeatable read )	事务级	否	否	是
可序列化( Serializable )	最高级别,事务级	否	否	否

• 数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在- -定程度上“串行化”进
• 行，这显然与“并发”是矛盾的。同时，不同的应用对读一 致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读
• 和“幻读”并不敏感，可能更关心数据并发访问的能力。

查看当前数据库的事物隔离级别

show variables like 'tx_isolation';

设置当前session事物隔离级别

set session transaction isolation  level repeatable read;

行级锁案例

# 建表语句
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
# 开启两个session关闭自动提交
set autocommit =0;
# 在session1中修改记录
update test_innodb_lock set b = '4001' where a = 4;
# 在session1查询
select * from test_innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4001 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9000 |
| 1 | b1   |
+---+------+
# 在session2中查询
select * from test_innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4000 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9000 |
| 1 | b1   |
+---+------+
# 在session1中提交
commit;
# 在sessinn2中查看
select * from test_innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4001 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9000 |
| 1 | b1   |
+---+------+
# 这是在 session1中设置
 update test_innodb_lock set b = '4002' where a = 4;
 # 这是在 session2中设置->被阻塞
 update test_innodb_lock set b = '4003' where a = 4;
# 这时候在session1中执行
commit;
# 这时候 session2中执行成功
;
# 测试不操作同一行
# session1执行
update test_innodb_lock set b = '4005' where a = 4;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0
# session2执行
update test_innodb_lock set b = '9001' where a = 9;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

无索引行锁升级为表锁

#还原所有记录
 # 在session1执行中
 update test_innodb_lock set a = 41 where b='4000';
 commit;
 # 在session2执行中
 update test_innodb_lock set b = '9001' where a = 9;
 commit;

间隙锁危害

# 表数据
select * from test_innodb_lock;
+---+------+
| a | b    |
+---+------+
| 1 | b2   |
| 3 | 3    |
| 4 | 4000 |
| 5 | 5000 |
| 6 | 6000 |
| 7 | 7000 |
| 8 | 8000 |
| 9 | 9002 |
| 1 | b1   |
+---+------+
# 在session1中执行
update test_innodb_lock set b='0629' where a > 1 and a<6; 
# 在session2中执行-> 发生阻塞
insert into test_innodb_lock values(2,'2000');
# 在session1中执行
commit;
# 在session2返回的结果是
Query OK, 1 row affected (26.47 sec)

间隙锁总结

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

锁定某一行

select * from test_innodb_lock where a = 'a1' from update

2.3 页锁

• 开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度-一般。
• 了解一下即可

结论

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

[如何分析行锁定]

• 通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like'innodb_row_1ock%';
show status like'innodb_row_lock%';
+-------------------------------+--------+
| Variable_name                 | Value  |
+-------------------------------+--------+
| Innodb_row_lock_current_waits | 0      |
| Innodb_row_lock_time          | 136321 |
| Innodb_row_lock_time_avg      | 11360  |
| Innodb_row_lock_time_max      | 51003  |
| Innodb_row_lock_waits         | 12     |
+-------------------------------+--------+
对各个状态量的说明如下:
Innodb_ _row_ lock_ current_ _waits: 当前正在等待锁定的数量;
Innodb_ row_ lock_ time: 从系统启动到现在锁定总时间长度;
Innodb_ row_ _lock_ _time_ avg: 每次等待所花平均时间;
Innodb_ row_ lock_ ftime_ max: 从系统启动到现在等待最常的一次所花的时间;
Innodb_ _row_ lock_ _waits: 系统启动后到现在总共等待的次数;

优化建议

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