MYISAM锁模式
mysql的表锁有两种模式:表共享读锁(table read lock)和表独占写锁(table write lock)
说明 1.myISAM表的读操作,不会阻塞其他用户对同一个表的读请求,但会阻塞对同一个表的写请求。
2.myISAM表的写操作,会阻塞其他用户对同一个表的读和写操作。
3.myISAM表的读、写操作之间、以及写操作之间是串行的。
innodb行锁模式
innoDB实现了以先两种类型的行锁:
共享锁(S):允许一个事务去读一行,阻止其他事务获取相同数据集的排他锁。
排他锁(X):允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和排他写锁。
先两种意向表锁(都是表所):
意向同享锁
意向排他锁
事务的四大隔离级别
隔离级别特性
未提交读(read uncommitted)
事务A对数据进行修改,但未提交。
此时开启事务B,在事务B中能读到事务A中对数据库进行的未提交数据的修改。
提交读(read committed)
事务A对数据进行修改,但还未提交。
此时开启事务B,在事务B中不能读到事务A中对数据库的修改。在事务B还没有关闭时,此时事务A提交对数据库的修改。这时候,我们在事务B中,可以查到事务A中对数据库的修改。这时存在一个问题,我们在同一个事务中,对数据库查询两次,但两次的结果是不一样的。
可重复读(repetition read)。
在同一个事务内的查询都是事务开始时刻一致的,InnoDB默认级别。
事务A在读到一条数据之后,此时事务B对该数据进行了修改并提交,那么事务A再读该数据,读到的还是原来的内容。
在SQL标准中,该隔离级别消除了不可重复读,但是还存在幻象读
串行化(serializable)
在开启事务A时,会产生锁表,此时别的事务会等待,等事务A结束时才会开启。
一般数据库都不会采用,因为无论做什么操作都不会加锁,不具备可用性。
1、原理
MySQL默认的隔离级别是可重复读
即:事务A在读到一条数据之后,此时事务B对该数据进行了修改并提交,那么事务A再读该数据,读到的还是原来的内容。 那么MySQL可重复读是如何实现的呢?
使用的的一种叫MVCC的控制方式 ,即Mutil-Version Concurrency Control,多版本并发控制,类似于乐观锁的一种实现方式
实现方式:
InnoDB在每行记录后面保存两个隐藏的列来,分别保存了这个行的创建时间和行的删除时间。这里存储的并不是实际的时间值,而是系统版本号,当数据被修改时,版本号加1
在读取事务开始时,系统会给当前读事务一个版本号,事务会读取版本号<=当前版本号的数据
此时如果其他写事务修改了这条数据,那么这条数据的版本号就会加1,从而比当前读事务的版本号高,读事务自然而然的就读不到更新后的数据了
2、增删改查
“等价判断”可见性的原则:
- 版本未提交,不可见;
- 版本已提交,但是是在快照创建后提交的,不可见;
- 版本已提交,而且是在快照创建前提交的,可见。
这其实就是可重复读的想要实现的效果。
- “快照”不是全量拷贝,而是利用了数据多版本的特性,也就是MVCC
- MVCC的核心在于每个事务自己维护的一个事务ID数组
- 可以用“等价原则”来判断数据版本的可见性
1. 索引
索引,类似书籍的目录,可以根据目录的某个页码立即找到对应的内容。
索引的优点:1. 天生排序。2. 快速查找。
索引的缺点:1. 占用空间。2. 降低更新表的速度。
注意点:小表使用全表扫描更快,中大表才使用索引。超级大表索引基本无效。
索引从实现上说,分成 2 种:聚集索引和辅助索引(也叫二级索引或者非聚集索引)
从功能上说,分为 6 种:普通索引,唯一索引,主键索引,复合索引,外键索引,全文索引。
详细说说 6 种索引:
- 普通索引:最基本的索引,没有任何约束。
- 唯一索引:与普通索引类似,但具有唯一性约束。
- 主键索引:特殊的唯一索引,不允许有空值。
- 复合索引:将多个列组合在一起创建索引,可以覆盖多个列。
- 外键索引:只有InnoDB类型的表才可以使用外键索引,保证数据的一致性、完整性和实现级联操作。
- 全文索引:MySQL 自带的全文索引只能用于 InnoDB、MyISAM ,并且只能对英文进行全文检索,一般使用全文索引引擎(ES,Solr)。
注意:主键就是唯一索引,但是唯一索引不一定是主键,唯一索引可以为空,但是空值只能有一个,主键不能为空。
另外,InnoDB 通过主键聚簇数据,如果没有定义主键且没有定义聚集索引, MySql 会选择一个唯一的非空索引代替,如果没有这样的索引,会隐式定义个 6 字节的主键作为聚簇索引,用户不能查看或访问。
简单点说:
- 设置主键时,会自动生成一个唯一索引,如果之前没有聚集索引,那么主键就是聚集索引。
- 没有设置主键时,会选择一个不为空的唯一索引作为聚集索引,如果还没有,那就生成一个隐式的 6 字节的索引。
MySql 将数据按照页来存储,默认一页为 16kb,当你在查询时,不会只加载某一条数据,而是将这个数据所在的页都加载到 pageCache 中,这个其实和 OS 的就近访问原理类似。
MySql 的索引使用 B+ 树结构。在说 B+ 树之前,先说说 B 树,B 树是一个多路平衡查找树,相较于普通的二叉树,不会发生极度不平衡的状况,同时也是多路的。
B 树的特点是:他会将数据也保存在非页子节点。
看图可知:
而这个特点会导致非页子节点不能存储大量的索引。
而 B+ Tree 就是针对这个对 B tree 做了优化。如下图所示:
我们看到,B+ Tree 将所有的 data 数据都保存到了叶子节点中,非也子节点只保存索引和指针。
我们假设一个非页子节点是 16kb,每个索引,即主键是 bigint,即 8b,指针为 8b。那么每页能存储大约 1000 个索引(16kb/ 8b + 8b).
而一颗 3 层的 B+树能够存储多少索引呢?如下图:
大约能够存储 10 亿个索引。通常 B+ 树的高度在 2-4 层,由于 MySql 在运行时,根节点是常驻内存的,因此每次查找只需要大约 2 -3 次 IO。可以说,B+ 树的设计,就是根据机械磁盘的特性来进行设计的。
知道了索引的设计,我们能够知道另外一些信息:
- MySql 的主键不能太大,如果使用 UUID 这种,将会浪费 B+ 树的非叶子节点。
- MySql 的主键最好是自增的,如果使用 UUID 这种,每次插入都会调整 B+树,从而导致页分裂,严重影响性能。
那么,如果项目中使用了分库分表,我们通常都会需要一个主键进行 sharding,那怎么办呢?在实现上,我们可以保留自增主键,而逻辑主键用来作为唯一索引即可。
2. 锁机制
关于 Mysql 的锁,各种概念就会喷涌而出,事实上,锁有好几种维度,我们来解释一下。
1. 类型维度
- 共享锁(读锁 / S 锁)
- 排它锁(写锁 / X 锁)
类型细分:- 意向共享锁
- 意向排他(互斥)锁
- 悲观锁(使用锁,即 for update)
- 乐观锁(使用版本号字段,类似 CAS 机制,即用户自己控制。缺点:并发很高的时候,多了很多无用的重试)
2. 锁的粒度(粒度维度)
- 表锁
- 页锁(Mysql BerkeleyDB 引擎)
- 行锁(InnoDB)
3. 锁的算法(算法维度)
- Record Lock(单行记录)
- Gap Lock(间隙锁,锁定一个范围,但不包含锁定记录)
- Next-Key Lock(Record Lock + Gap Lock,锁定一个范围,并且锁定记录本身, MySql 防止幻读,就是使用此锁实现)
4. 默认的读操作,上锁吗?
- 默认是 MVCC 机制(“一致性非锁定读”)保证 RR 级别的隔离正确性,是不上锁的。
可以选择手动上锁:select xxxx for update (排他锁); select xxxx lock in share mode(共享锁),称之为“一致性锁定读”。
使用锁之后,就能在 RR 级别下,避免幻读。当然,默认的 MVCC 读,也能避免幻读。
既然 RR 能够防止幻读,那么,SERIALIZABLE 有啥用呢?
防止丢失更新。例如下图:
这个时候,我们必须使用 SERIALIZABLE 级别进行串行读取。
最后,行锁的实现原理就是锁住聚集索引,如果你查询的时候,没有正确地击中索引,MySql 优化器将会抛弃行锁,使用表锁。
3. 事务
事务是数据库永恒不变的话题, ACID:原子性,一致性,隔离性,持久性。
四个特性,最重要的就是一致性。而一致性由原子性,隔离性,持久性来保证。
- 原子性由 Undo log 保证。Undo Log 会保存每次变更之前的记录,从而在发生错误时进行回滚。
- 隔离性由 MVCC 和 Lock 保证。这个后面说。
- 持久性由 Redo Log 保证。每次真正修改数据之前,都会将记录写到 Redo Log 中,只有 Redo Log 写入成功,才会真正的写入到 B+ 树中,如果提交之前断电,就可以通过 Redo Log 恢复记录。
然后再说隔离性。
隔离级别:
- 未提交读(RU)
- 已提交读(RC)
- 可重复读(RR)
- 串行化(serializable)
每个级别都会解决不同的问题,通常是3 个问题:脏读,不可重复读,幻读。一张经典的图:
这里有个注意点,关于幻读,在数据库规范里,RR 级别会导致幻读,但是,由于 Mysql 的优化,MySql 的 RR 级别不会导致幻读:在使用默认的 select 时,MySql 使用 MVCC 机制保证不会幻读;你也可以使用锁,在使用锁时,例如 for update(X 锁),lock in share mode(S 锁),MySql 会使用 Next-Key Lock 来保证不会发生幻读。前者称为快照读,后者称为当前读。
原理剖析:
- RU 发生脏读的原因:RU 原理是对每个更新语句的行记录进行加锁,而不是对整个事务进行加锁,所以会发生脏读。而 RC 和 RR 会对整个事务加锁。
- RC 不能重复读的原因:RC 每次执行 SQL 语句都会生成一个新的 Read View,每次读到的都是不同的。而 RR 的事务从始至终都是使用同一个 Read View。
- RR 不会发生幻读的原因: 上面说过了。
那 RR 和 Serializble 有什么区别呢?答:丢失更新。本文关于锁的部分已经提到。
MVCC 介绍:全称多版本并发控制。
innoDB 每个聚集索引都有 4 个隐藏字段,分别是主键(RowID),最近更改的事务 ID(MVCC 核心),Undo Log 的指针(隔离核心),索引删除标记(当删除时,不会立即删除,而是打标记,然后异步删除);
本质上,MVCC 就是用 Undo Log 链表实现。
MVCC 的实现方式:事务以排它锁的方式修改原始数据,把修改前的数据存放于 Undo Log,通过回滚指针与数据关联,如果修改成功,什么都不做,如果修改失败,则恢复 Undo Log 中的数据。
多说一句,通常我们认为 MVCC 是类似乐观锁的方式,即使用版本号,而实际上,innoDB 不是这么实现的。当然,这不影响我们使用 MySql。