MySQL进阶
- 1. 存储引擎
- 1.1 体系结构
- 1.2 存储引擎
- 1.3 存储引擎特点
- 1.3.1 InnoDB
- 1.3.2 MyISAM
- 1.3.3 Memory
- 1.3.4 区别及特点
- 1.4 存储引擎选择
- 2. 索引
- 2.1 概述
- 2.2 索引结构
- 2.2.1 概述
- 2.2.2 二叉树
- 2.2.3 B-Tree
- 2.2.4 B+Tree
- 2.2.5 Hash
- 2.3 索引分类
- 2.3.1 索引分类
- 2.3.2 聚集索引&二级索引
- 2.4 索引语法
- 2.5 SQL性能分析
- 2.5.1 SQL执行频率
- 2.5.2 慢查询日志
- 2.5.3 profile详情
- 2.5.4 explain
- 2.6 索引使用
- 2.6.1 最左前缀法则
- 2.6.2 范围查询
- 2.6.3 索引失效情况
- 1. 索引列运算
- 2. 字符串不加引号
- 3. 模糊查询
- 4. or 连接条件
- 5. 数据分布影响
- 2.6.4 SQL提示
- 2.6.5 覆盖索引
- 2.6.5 前缀索引
- 2.6.7 单列索引与联合索引
1. 存储引擎
1.1 体系结构
- 连接层
- 服务层
- 引擎层
- 存储层
1.2 存储引擎
- 存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式
- 存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型
- 可以在创建表的时候,来指定存储引擎,如果没有指定将自动选择默认InnoDB
# 建表时指定存储引擎
CREATE TABLE 表名(
字段1 字段1类型 [ COMMENT 字段1注释 ],
......
字段n 字段n类型 [COMMENT 字段n注释 ]
) ENGINE = INNODB [ COMMENT 表注释 ];# 查询当前数据库支持的存储引擎
show engines;
1.3 存储引擎特点
面试题:
InnoDB引擎与MyISAM引擎的区别 ?
①. InnoDB引擎, 支持事务, 而MyISAM不支持。
②. InnoDB引擎, 支持行锁和表锁, 而MyISAM仅支持表锁, 不支持行锁。
③. InnoDB引擎, 支持外键, 而MyISAM是不支持的。
1.3.1 InnoDB
介绍:
- InnoDB是一种兼顾高可靠性和高性能的通用存储引擎,在 MySQL 5.5 之后,InnoDB是默认的MySQL 存储引擎
特点:
- DML操作遵循ACID模型,支持事务
- 行级锁,提高并发访问性能
- 支持外键FOREIGN KEY约束,保证数据的完整性和正确性;
文件:
- xxx.ibd:xxx代表的是表名,innoDB引擎的每张表都会对应这样一个表空间文件,存储该表的表结构(frm-早期的 、sdi-新版的)、数据和索引。
逻辑存储结构:
1.3.2 MyISAM
介绍:
- MyISAM是MySQL早期的默认存储引擎
特点:
- 不支持事务,不支持外键
- 支持表锁,不支持行锁
- 访问速度快
文件:
- xxx.sdi:存储表结构信息
- xxx.MYD: 存储数据
- xxx.MYI: 存储索引
1.3.3 Memory
介绍:
- Memory引擎的表数据是存储在内存中的,由于受到硬件问题、或断电问题的影响,只能将这些表作为临时表或缓存使用
特点:
- 内存存放, 速度快
- hash索引(默认)
文件:
- xxx.sdi:存储表结构信息
1.3.4 区别及特点
1.4 存储引擎选择
-
InnoDB: 是Mysql的默认存储引擎,支持事务、外键。如果应用对事务的完整性有比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包含很多的更新、删除操作,那么InnoDB存储引擎是比较合适的选择
-
MyISAM(MongDB替代了): 如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不是很高,那么选择这个存储引擎是非常合适的
-
MEMORY(Redis替代了):将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。缺陷就是对表的大小有限制,太大的表无法缓存在内存中,而且无法保障数据的安全性
2. 索引
2.1 概述
索引(index)是帮助MySQL 高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据, 这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引。
劣势可忽略
2.2 索引结构
2.2.1 概述
MySQL的索引是在存储引擎层实现的,不同的存储引擎有不同的索引结构,主要包含以下几种:
注意: 平常所说的索引,如果没有特别指明,都是指B+树结构组织的索引
2.2.2 二叉树
二叉树作为索引结构,会存在以下缺点:
- 顺序插入时,会形成一个链表,查询性能大大降低—>红黑树解决
- 大数据量情况下,层级较深,检索速度慢—>B树解决
2.2.3 B-Tree
B-Tree,B树是一种多叉路衡查找树,相对于二叉树,B树每个节点可以有多个分支,即多叉。
数据结构可视化网站
特点:
- 5阶的B树,每一个节点最多存储4个key,对应5个指针
- 一旦节点存储的key数量到达5,就会裂变,中间元素向上分裂
- 在B树中,非叶子节点和叶子节点都会存放数据
2.2.4 B+Tree
两部分:
-
绿色虚线框起来的部分,是索引部分,仅仅起到索引数据的作用,不存储数据
-
红色虚线框起来的部分,是数据存储部分,在其叶子节点中要存储具体的数据
-
所有的数据都会出现在叶子节点
-
叶子节点形成一个单向链表
-
非叶子节点仅仅起到索引数据作用,具体的数据都是在叶子节点存放的。
MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上,增加一个指向相邻叶子节点的链表指针,就形成了带有顺序指针的B+Tree,提高区间访问的性能,利于排序。
2.2.5 Hash
MySQL中除了支持B+Tree索引,还支持一种索引类型—Hash索引。
1). 结构
哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中。
如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了=hash冲突(也称为hash碰撞),可以通过链表来解决。
2). 特点
- Hash索引只能用于对等比较(=,in),不支持范围查询(between,>,< ,…)
- 无法利用索引完成排序操作
- 查询效率高,通常(不存在hash冲突)只需要一次检索就可以,效率通常要高于B+tree索引
3). 存储引擎支持
在MySQL中,支持hash索引的是Memory存储引擎。 而InnoDB中具有自适应hash功能,hash索引是InnoDB存储引擎根据B+Tree索引在指定条件下自动构建的
面试题:
为什么InnoDB存储引擎选择使用B+tree索引结构?
A. 相对于二叉树,层级更少,搜索效率高;
B. 对于B-tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储的键值减少,指针跟着减少,要同样保存大量数据,只能增加树的高度,导致性能降低;
C. 相对Hash索引,B+tree支持范围匹配及排序操作;
2.3 索引分类
2.3.1 索引分类
2.3.2 聚集索引&二级索引
在在InnoDB存储引擎中,根据索引的存储形式,又可以分为以下两种
聚集索引选取规则:
- 如果存在主键,主键索引就是聚集索引。
- 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引。
- 如果表没有主键,或没有合适的唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索引
执行如下的SQL语句时,具体的查找过程是:
具体过程如下:
- 由于是根据name字段进行查询,所以先根据name='Arm’到name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到 Arm 对应的主键值 10
- 由于查询返回的数据是*,所以此时,还需要根据主键值10,到聚集索引中查找10对应的记录,最终找到10对应的行row
- 最终拿到这一行的数据,直接返回即可。
回表查询: 这种先到二级索引中查找数据,找到主键值,然后再到聚集索引中根据主键值,获取数据的方式,就称之为回表查询。
思考题:
以下两条SQL语句,那个执行效率高? 为什么?
A. select * from user where id = 10 ;
B. select * from user where name = ‘Arm’ ;
备注: id为主键,name字段创建的有索引;解答:
A 语句的执行性能要高于B 语句。
因为A语句直接走聚集索引,直接返回数据。 而B语句需要先查询name字段的二级索引,然后再查询聚集索引,也就是需要进行回表查询。
2.4 索引语法
# 创建索引
CREATE [ UNIQUE | FULLTEXT ] INDEX index_name ON table_name (index_col_name,... );# 查看索引
show index from tb_name;# 删除索引
drop index index_name in tb_name;
2.5 SQL性能分析
2.5.1 SQL执行频率
-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
show [session||global] status like 'com_______'; # 七个下划线
2.5.2 慢查询日志
慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认10秒)的所有SQL语句的日志
- 开启慢查询日志,需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息:
# 开启MySQL慢日志查询开关 默认关闭
slow_query_log=1
# 设置慢日志的时间为2秒,SQL语句执行时间超过2秒,就会视为慢查询,记录慢查询日志
long_query_time=2# 重启
systemctl restart mysqld# 日志信息保存路径
/var/lib/mysql/localhost-slow.log
2.5.3 profile详情
# 查看是否支持profile
SELECT @@have_profiling ;# 开启
SET profiling = 1;
-- 查看每一条SQL的耗时基本情况
show profiles;
-- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
-- 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;
2.5.4 explain
EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序
-- 直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;
Explain 执行计划中各个字段的含义:
注意type尽量往前, 性能越高
2.6 索引使用
2.6.1 最左前缀法则
- 如果索引引了多列(联合索引),要遵循最左前缀法则。
- 最左前缀法则:查询从索引的最左列开始,并且不跳过索引中的列。
- 如果跳过某一列,索引将会部分失效
最左前缀法则中指的最左边的列,是指在查询时,联合索引的最左边的字段(即是第一个字段)必须存在,与我们编写SQL时,条件编写的先后顺序无关。
2.6.2 范围查询
- 联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效。
- 当范围查询使用>= 或 <= 时,走联合索引
- 业务允许情况下,尽可能使用 >= 或 <=
2.6.3 索引失效情况
1. 索引列运算
索引列运算会导致索引失效
2. 字符串不加引号
如果字符串不加单引号,对于查询结果,没什么影响,但是数据库存在隐式类型转换,索引将失效
3. 模糊查询
如果仅仅是尾部模糊匹配,索引不会失效。如果是头部模糊匹配,索引失效
4. or 连接条件
用 or 分割开的条件, 如果 or 前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会被用到
5. 数据分布影响
MySQL在查询时,会评估使用索引的效率与走全表扫描的效率,如果走全表扫描更快,则放弃索引,走全表扫描。 因为索引是用来索引少量数据的,如果通过索引查询返回大批量的数据,则还不如走全表扫描来的快,此时索引就会失效。
2.6.4 SQL提示
SQL提示,是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化操作的目的
- use index(index_name)
- ignore index(index_name)
- force index(index_name)
2.6.5 覆盖索引
覆盖索引是值 查询使用了索引,并且需要返回的列,在该索引中已经全部能够找到。
尽量使用覆盖索引,减少使用select *
注意最后一个字段Extra:
思考题:
一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案:
select id,username,password from tb_user where username = ‘itcast’;
答案: 针对于 username, password建立联合索引, sql为:
create index idx_user_name_pass on tb_user(username,password);
这样可以避免上述的SQL语句,在查询的过程中,出现回表查询。
2.6.5 前缀索引
当字段类型为字符串时(varchar,text,longtext),有时候需要索引很长的字符串,影响查询效率。此时可以将字符串的一部分前缀,建立索引,提高效率
- 前缀长度:不重复索引值和数据表的记录总数的比值
- 查询流程:先根据索引查到记录,再进行回表查询
2.6.7 单列索引与联合索引
单列索引:即一个索引只包含单个列
联合索引:即一个索引包含了多个列
在业务场景中,如果存在多个查询条件,考虑针对于查询字段建立索引时,建议建立联合索引,而非单列索引