深入了解MySQL,一篇简短的总结
耶low 人气:0MySQL的基本语法
这里作为MySQL部分模块的深入了解,大部分都是理论方面的笔记,不会写具体用法。
具体用法会记录在下面这个随笔分类下,不过暂时还没更新完,等过段时间会更新下事务、存储过程、索引等用法,虽然都很简单,就当做个完整的笔记。
https://www.cnblogs.com/lbhym/category/1493919.html
一个关系型数据库的基本模块
以下模块也不一定是各大数据库实际的模块,但是都差不多,只是大概了解一下数据库的架构。
除了硬件,也就是存储部分,是由磁盘组成,在软件部分主要分为一下几个模块:
存储管理:用于管理数据格式,把物理数据通过逻辑的形式组织表现出来,即数据实际都是存在物理的磁盘当中,需要在软件层面做一个逻辑上的组织管理。
缓存机制:影响数据库性能的一大问题就是IO,所以会将取出来的数据放入内存当中,使用时直接从内存返回。即使目前非常快的固态硬盘也远远比不上内存的速度。
SQL解析:将SQL解析成机器可读的语言。
日志管理:记录用户对数据库的操作。
权限划分:字面意思,非常常见的一个功能,将不同的用户分为不同的角色,操作权限也不同。
容灾机制:这个部分较为复杂,大概作用就是当数据库发生异常灾难时该怎么恢复。
索引管理:优化数据库查询效率。
锁管理:使数据库支持并发操作。
Mysql索引的实现,B+树
索引是优化数据库查询效率,普通的查询是全表查询,当数据量过大时会严重影响性能。
而索引就像一本词典的目录,在数据量较大时会增加查询效率,但是如果频繁的更新或删除数据,同时也需要去维护索引,反而会降低性能,所以索引不宜太多。
索引实际上也是一个文件,既然需要高效的查找当然也需要一个好的数据结构,关于索引的实现,有B树、二叉查找树等,这里只讲MySQL的B+树。
B+树的特点和插入删除过程想过很多文字描述,但是总有点说不清。推荐看看这篇博客,过程图文表现的很清楚。
https://blog.csdn.net/login_sonata/articlehttps://img.qb5200.com/download-x/details/75268075
为什么会选择B+树?
B+树的一个特点就是其叶子结点均有一个链指针指向下一个叶子结点,再加上其是有序的,所以我们进行范围查询时,比如查询>10的数据,只需要先找到10,再直接通过叶子结点的指针就能找到其余数据。
而其他结构还需从根节点出发接着找。
联合索引最左匹配原则
联合索引,有的叫组合索引、有的叫复合索引,叫法无所谓,大概是那个意思就行。
1.一张表里有字段A、B,当我们需要查询where A=‘xxx’ and B='xxx',在这种场景下我们就可以使用联合索引。
而最左匹配原则就是,当创建索引时,语句如下
alter table TABLENAME add index index_name(A,B)
其中A在左边,那么如果我们只查询A时,会用到这个联合索引,而只查询B时,不会用到这个联合索引。
2.还有种情况,在联合索引中,mysql会从左往右匹配,直到遇到>、<、between、like就会停止。
比如联合索引中有四个字段A,B,C,D。where A=1 and B=2 and C>3 and D=4。其中ABC会用到索引,而D不会。如果在定义索引时交换C,D的位置,ABCD就都会使用索引
alter table TABLENAME add index index_name(A,B,C,D)-->alter table TABLENAME add index index_name(A,B,D,C)
所以最左匹配原则是依据定义索引时的顺序,查询时顺序如何不影响(因为mysql查询优化器会帮我们优化查询顺序)。
最左匹配原则的原理
索引的底层是B+树,联合索引也一样。但是联合索引特殊的就是有多个值,而构建B+树只需一个值,mysql选择最左的那一个字段当值。
上图是一个联合索引下的B+树,假如字段分别对应(A,B),可以发现A的值是有序的(1,1,2,2,3,3),B是无序的(1,2,1,4,1,2),所以当我们直接查找B=2时是无法通过索引找的。
因为这个B+树是按A的值形成的,B的值完全不符合B+树特性,所以无法单独找到B。
那为先找到A后,就能找到B了?
大家仔细观察这个树,在A相等的区间内,B是有序的。
还有就是,为什么遇到范围查询就停止了。范围查询是针对全表的,而非最左的字段只是区间内有序。
MySQL两种引擎:MyISAM和InnoDB
简短地说
Myisam:是非聚集索引,不支持事务,只支持表级锁。
InnoDB:是聚集索引,支持事务,默认是行级锁,支持表级锁。
下面就这三个方面一一说明。
聚集索引
定义:数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。即索引键值的逻辑顺序决定了表中相应行的物理顺序。
网上有个很好的例子,就是把聚集索引比作一本字典的拼音目录。而数据就是字典里面的字。拼音目录是按照一定顺序排列的,那么字典后面的字也一定是根据拼音的顺序排列的。
当我们在拼音B处插入一个新汉字,那么B后面所有的汉字要向后移动,不可能是加在字典最后面的,因为它得按拼音顺序排列。
所以聚集索引适用于:范围查询,比如<,>,=,between等,还有分组group by,因为B+树是有序的,所以分组的效率也更高。
不适用于:频繁更改的列。
非聚集索引
定义:该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同,一个表中可以拥有多个非聚集索引。
即索引在一个地方,数据在一个地方,索引带有指向数据的指针。这在物理上也体现出来了,在数据库目录下,索引存在.MYI文件下,数据存在.MYD文件下。上面的聚集索引,数据和索引在同一个文件下.ibd。
而数据的顺序和索引不一样,所以聚集索引适用于:频繁修改索引列。
表级锁和行级锁
两种锁即字面意思。表级锁,mysql中最大粒度得到锁,锁住整张数据表。行级锁,mysql中最小粒度的锁,只锁住操作的那一行,本表中其他行不锁。
而针对不同的操作,锁的具体类别又有所不同,为了不混淆,大家可以把表级锁和行级锁当作锁的范围。而下面说到的锁当作具体的分类。
当Myisam查询时:会在整张表的范围上加上读锁,又叫共享锁。当加上读锁,其他sql的想增删改时就会被阻塞,必须等待查询完毕。又叫共享锁的原因是,可以同时在同一张表内做查询。
当Myisam增删改时:会在整张表的范围上加上写锁,又叫排他锁。当加上写锁,其他sql不论是增删改还是查询都会被阻塞。又叫排他锁的原因是,即使我修改的是1-10行数据,你查询第11行数据也会被阻塞。
上面说的是MyISAM引擎的情况,InnoDB在读锁、写锁上的逻辑也是一样的,只是锁范围变成了行。
大家在mysql上实验InnoDB的锁时:要注意,InnoDB对select进行了优化,并未对select语句加上读锁,也就是非阻塞select,大家可以在select语句后面加上lock in share mode手动加上读锁。
具体怎么实验:1.往表中插入几百万条的数据,增删改查时在范围内进行,这样就可以模拟阻塞环境了。2.InnoDB支持事务,不过其是自动提交的,还得用set autocommit=0取消自动提交。这样在commit之前就是阻塞状态。
事务
简单的说,就是使多步操作具有原子性。即在事务内执行多条SQL语句,要么全部成功,要么全部不成功,不会存在部分执行成功,而导致数据不一致的情况。
事务具有四大特性:
- 原子性,上面说到的。
- 一致性,事务前后数据的完整性必须保持一致。
- 隔离性,多个用户事务并发进行时,不能互相干扰。
- 持久性,一旦事务提供,其修改的结果是永久存在的。
重点说说隔离性。如果事务间没有隔离会发生什么情况呢。
假如有一个场景:事务A获取到一个数据为900,此时另外一个事务B在事务A提交之前就修改了数据到800,并提示成功。
而事务A的操作数据依旧是查询时的900,并进行+100,变成了1000。显然结果是不对的,这就是更新丢失问题。
这个问题是不是很像多线程并发操作,但是没有锁时就会发生的问题。实际上,事务的隔离就是用锁来实现的。
了解隔离级别之前需要知道几个概念:
脏读:事务A读取到了事务B还未提交的数据。
不可重复读:事务A多次查询数据时,事务B对该数据做了修改并提交,此时事务A发现多次查询前后结果不一样。
在我们看来仿佛没什么问题,一个事务修改了数据,一个事务查询到了修改后的结果。但有个问题就是,事务A是多次查询,如果他没有多次查询,直接在第一次查询的结果上操作,那么是不是就会出现问题。
幻读:事务A查询了一段数据集,事务B修改了事务A的数据集范围内的某些数据,导致查询结果和实际结果不一致。
了解了这三个概念后就可以很好的理解几个隔离级别:
隔离级别 | 脏读 | 不可重复读 | 幻读 |
未提交读(Read uncommitted) | 可能 | 可能 | 可能 |
已提交读(Reda committed) | 不可能 | 可能 | 可能 |
可重复读(Repeatable read) | 不可能 | 不可能 | 可能 |
可串行化(Serializable) | 不可能 | 不可能 | 不可能 |
隔离级别越高,安全性越高,性能也越低,所以要根据实际业务设置不同的隔离级别。
举个例子:如果设置的是可串行化隔离级别,事务A对TableA的1-10行进行操作,事务B即使对TableA的第11行进行操作也会被阻塞。对于这种业务没必要设置为可串行化隔离级别。
加载全部内容