文章目录
聊聊 MyISAM和InnoDB区别
这里主要是介绍锁,简单讲述前言
-
锁
- MyISAM :支持表锁
- InnoDB:支持
行级锁
,InnoDB表的行锁也不是绝对的,如果在执行一个SQL语句时MySQL不能确定要扫描的范围,InnoDB表同样会锁全表(非索引后面会讲),还要注意间隙锁的影响
-
事务
- InnoDB
具有事务
,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID。如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能 - MyISAM管理
非事务
表。它提供高速存储和检索,以及全文搜索能力。如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择
- InnoDB
MySQL 事务属性
事务是由一组SQL语句组成的逻辑处理单元 ,事务具有ACID属性。
-
原子性
(Atomicity):事务是一个原子操作单元。在当时原子是不可分割的最小元素,其对数据的修改,要么全部成功,要么全部都不成功。 -
一致性
(Consistent):事务开始到结束的时间段内,数据都必须保持一致状态。 -
隔离性
(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的"独立"环境执行。 -
持久性
(Durable):事务完成后,它对于数据的修改是永久性的,即使出现系统故障也能够保持
MySQL事务常见的问题
更新丢失
(Lost Update)
- 原因:当多个事务选择同一行操作,并且都是基于最初选定的值,由于每个事务都不知道其他事务的存在,就会发生更新覆盖的问题。类比github提交冲突。
脏读
(Dirty Reads)
- 原因:事务A读取了事务B已经修改但尚未提交的数据。若事务B回滚数据,事务A的数据存在不一致性的问题。
不可重复读
(Non-Repeatable Reads)
- 原因:事务A第一次读取最初数据,第二次读取事务B已经提交的修改或删除数据。导致两次读取数据不一致。不符合事务的隔离性。
幻读
(Phantom Reads)
- 原因:事务A根据相同条件第二次查询到事务B提交的新增数据,两次数据结果集不一致。不符合事务的隔离性。
幻读和脏读有点类似,脏读是事务B里面修改了数据,幻读是事务B里面新增了数据
事务隔离级别
数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大。这是因为事务隔离实质上是将事务在一定程度上"串行"进行,这显然与"并发"是矛盾的。根据自己的业务逻辑,权衡能接受的最大副作用。从而平衡了"隔离" 和 "并发"的问题。MySQL默认隔离级别是可重复读。脏读,不可重复读,幻读,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决
锁的分类: 主要的是表、行、页锁
-
按锁粒度从大到小分类:
表锁,页锁和行锁
;以及特殊场景下使用的全局锁
-
如果按锁级别分类则有:
共享(读)锁、排他(写)锁、意向共享(读)锁、意向排他(写)锁
; -
以及Innodb引擎为
解决幻读
等并发场景下事务存在的数据问题,引入的Record Lock(行记录锁
)、Gap Lock(间隙锁
)、Next-key Lock(Record Lock + Gap Lock结合)
等; -
还有就是我们面向编程的两种锁思想:
悲观锁、乐观锁
。
全局锁
-
全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法,命令是
Flush tables with read lock
。当需要让整个库处于只读状态的时候,可以使用这个命令,之后其他线程的以下语句会被阻塞:数据更新语句(数据的增删改)、数据定义语句(包括建表、修改表结构等)和更新类事务的提交语句 -
全局锁的典型使用场景是,做
全库逻辑备份
。也就是把整库每个表都select出来存成文本
但是让整个库都只读,可能出现以下问题
- 如果在主库上备份,那么在备份期间都不能执行更新,业务基本上就得停摆
- 如果在从库上备份,那么在备份期间从库不能执行主库同步过来的binlog,会导致主从延迟
既然要全库只读,为什么不使用
set global readonly=true(全库只读)
的方式?
- 在有些系统中,readonly的值会被用来做其他逻辑,比如用来判断一个库是主库还是备库。因此修改global变量的方式影响面更大
在异常处理机制上有差异。- 如果执行Flush tables with read lock命令之后由于客户端发生异常断开,那么MySQL会自动释放这个全局锁,整个库回到可以正常更新的状态。
- 而将整个库设置为readonly之后如果客户端发生异常,则数据库会一直保持readonly状态,这样会导致整个库长时间处于不可写状态,风险较高
表锁
主要是MyISAM下的表锁
-
表锁的优势:开销小;加锁快;无死锁
-
表锁的劣势:锁粒度大,发生锁冲突的概率高,并发处理能力低
-
MyISAM 在执行查询语句(SELECT)前,会
自动给涉及的所有表加读锁
,在执行更新操作(UPDATE、DELETE、INSERT 等)前,会自动给涉及的表加写锁
,这个过程并不需要用户干预。 -
但是为了测试,我们手动加锁
加读锁 : lock table 表名 read;
加写锁 : lock table 表名 write;
同时加读、写锁: lock table 表名 read , write;
查看表加锁情况: SHOW OPEN TABLES;
释放锁: UNLOCK TABLES;
- 表锁的语法是
lock tables … read/write
。可以用unlock tables
主动释放锁,也可以在客户端断开的时候自动释放。lock tables语法除了会限制别的线程的读写外,也限定了本线程接下来的操作对象 - 如果在某个线程A中执行lock tables t1 read,t2 wirte;这个语句,则其他线程写t1、读写t2的语句都会被阻塞。同时,线程A在执行unlock tables之前,也只能执行读t1、读写t2的操作。连写t1都不允许
表锁测试(读写锁)
读锁测试
- 准备两张表 student、teacher 引擎是MySAM
- T1线程去对student加读锁,发现是不能对其他表查询的
#取消自动提交
SET autocommit=0;
#给student加读锁
LOCK TABLE student READ;
#再对student查询是ok的
SELECT * FROM student;
#再对同库其他表查询,失败
#原因是因为我们已经对student加锁了
#这就相当于在12306中抢票一样,抢到了一张火车票,但是没有完成支付,就无法再购买另一张火车票。把student这张表锁定了,还没有释放锁,就不能再操作其他的表了
SELECT * FROM teacher;
- 但是用T2线程去查询student、teacher都是ok的
-
然后在用T1线程去对student写(更新,修改…)试试,发现不能操作
#写其他表也不行 UPDATE teacher SET `name`= 'tony' WHERE id =1;
- 再用T2线程去写student,发现线程阻塞了
- 我们试试把T1的锁释放
UNLOCK TABLES
,发现t2继续运行 并且修改成功了
- 总结
- MyISAM中T1线程对某一张表加了读锁,它不会阻塞其它线程的读操作,但是会阻塞其它线程的写操作。
- T1线程也不能对其他表进行读,写操作
写锁测试
- T1线程对student加上写锁,发现对student读写都ok,但是不能对其他表进行读写操作
#对student加写锁
LOCK TABLE student WRITE ;
#读写student都ok
SELECT * FROM student;
UPDATE student SET `name`= 'tony' WHERE id =1;
#释放锁
UNLOCK TABLES;
- 再让T2对student进行读写,发现线程阻塞,当T1去释放写锁时,T2立马执行成功,并且T2可以对其他表进行读写操作
- 总结读写锁
-
对MyISAM 表的读操作,不会阻塞其他用户对同一表的读请求,但会阻塞对同一表的写请求;
-
对MyISAM 表的写操作,则会阻塞其他用户对同一表的读和写操作
简而言之,就是读锁会阻塞写,但是不会阻塞读。而写锁,则既会阻塞读,又会阻塞写
此外,MyISAM 的读写锁调度是写优先,这也是MyISAM不适合做写为主的表的存储引擎的原因。因为写锁后,其他线程不能做任何操作,大量的更新会使查询很难得到锁,从而造成永远阻塞。
行锁
主要时InnoDB下的行锁
-
行锁的劣势:开销大;加锁慢;会出现死锁
-
行锁的优势:锁的粒度小,发生锁冲突的概率低;处理并发的能力强
-
加锁的方式:自动加锁,默认支持的是行级锁
-
InnoDB 实现了以下两种类型的行锁。
共享锁(S)
:又称为读锁,简称S锁,共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改。
排他锁(X)
:又称为写锁,简称X锁,排他锁就是不能与其他锁并存,如一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁,包括共享锁和排他锁,但是获取排他锁的事务是可以对数据就行读取和修改。 -
对于写(UPDATE、DELETE和INSERT)语句,InnoDB会
自动给涉及数据集加排他锁
-
对于普通SELECT语句,InnoDB不会加任何锁
-
当然事务可以通过显示的加锁:
共享锁(S) :SELECT * FROM 表名 WHERE ... LOCK IN SHARE MODE
排他锁(X) :SELECT * FROM 表名 WHERE ... FOR UPDATE
行锁测试(共享锁、排他锁)
-
准备student、teacher 引擎是InnoDB
-
#先关掉事务自动提交 set autocommit = 0;
-
T1线程对student中id=1进行写将名字改为Tom1(更新…),但是不提交;(已关闭自动提交)
UPDATE student SET `name`= 'tony' WHERE id =1;
- 然后让T2线程对id=1进行写将名字改Tom2,发现会阻塞
-
当T2线程手动commit的时候,发现T2恢复并正常执行,然后将T2事务提交commit,但是当我们查询的时候出现了问题
- 再T1线程中查询显示 name = Tom1
- 在T2线程中查询显示 name = Tom2
-
只能我们再次将T1进行commit才能发现 name = Tom2
当我们指定了更新语句,它会对我们这一行数据加上排它锁,当我们提交了之后,才会释放排他锁,另外一个客户端才可以解除阻塞状态。
【注意】
-
InnoDB行锁是通过给索引上的索引项加锁来实现的,InnoDB这种行锁实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁,实际效果跟表锁一样
-
查看当前表的索引 : show index from 表名;
测试没有索引的锁
- 查看student的索引,发现一个也没有
show index from student
- T1线程对student写
UPDATE student SET `name`= 'tony1' WHERE id =1
- 然后让T2线程对student写,发现也阻塞了,但是我们知道InnoDB默认是行锁,这里因为student没有索引升级为了表锁
意向锁
意向锁属于表级锁,其设计目的主要是为了在一个事务中
揭示下一行将要被请求锁的类型
。InnoDB 中的两个表锁其实相当于酒店的前台
-
意向共享锁(IS):表示事务准备给数据行加入共享锁,也就是说一个数据行加共享锁前必须先取得该表的IS锁;
-
意向排他锁(IX):类似上面,表示事务准备给数据行加入排他锁,说明事务在一个数据行加排他锁前必须先取得该表的IX锁。
意向锁是 InnoDB 自动加的,不需要用户干预。
InnoDB行锁争用情况
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: 系统启动后到现在总共等待的次数
-
总结行锁
- 行锁中读写锁的兼容性和表锁里面一样
- InnoDB存储引擎由于实现了行级锁定,虽然在锁定机制的实现方面带来了性能损耗可能比表锁会更高一些,但是在整体并发处理能力方面要远远高于MyISAM的表锁的。当系统并发量较高的时候,InnoDB的整体性能和MyISAM相比就会有比较明显的优势。
-
优化建议:
- 尽可能让所有数据检索都能通过索引来完成,避免无索引行锁升级为表锁。
- 合理设计索引,尽量缩小锁的范围
- 尽可能减少索引条件,及索引范围,避免间隙锁
- 尽量控制事务大小,减少锁定资源量和时间长度
- 尽可使用低级别事务隔离(但是需要业务层面满足需求)
间隙锁
- 当我们用范围条件,而不是使用相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据进行加锁; 对于键值在条件范围内但并不存在的记录,叫做 “间隙(GAP)” , InnoDB也会对这个 “间隙” 加锁,这种锁机制就是所谓的 间隙锁(Next-Key锁)
间隙锁则分为两种:Gap Locks
和Next-Key Locks
-
Gap Locks会锁住两个索引之间的区间,比如select * from User where id>3 and id<5 for update,就会在区间(3,5)之间加上Gap Locks。
-
Next-Key Locks是Gap Locks+Record Locks形成闭区间锁select * from User where id>=3 and id=<5 for update,就会在区间[3,5]之间加上Next-Key Locks。
测试 -
比如 修改T1线程对student中id<3的name修改,但是我们的数据中只有1,3。所以id=2这个数据没有,就会被加上间隙锁
- 再让T2线程去插入id = 2,发现阻塞了,只有T1commit然后T2在commit,T1再commit 这是数据就插入了(和行锁一样)
页锁
-
除了表锁、行锁外,MySQL还有一种相对偏中性的页级锁,页锁是MySQL中比较独特的一种锁定级别,在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间,所以获取锁定所需要的资源开销,以及所能提供的并发处理能力也同样是介于上面二者之间。另外,页级锁定和行级锁定一样,会发生死锁。
-
使用页级锁定的主要是BerkeleyDB存储引擎。
总结
参考博客
MySQL锁详解
面试让HR都能听懂的MySQL锁机制,欢声笑语中搞懂MySQL锁
MySQL高级-MySQL锁
MySQL常见的七种锁详细介绍