索引
索引概述
- 介绍
索引(index)是帮助MySQL高效获取数据的数据结构。数据库系统会定期维护索引,保证数据的高效查询。 - 演示
无索引:数据库的数据查找方式为全表顺序查找,即从第一行数据开始逐行扫描数据,直至最后一行结束。这种查找方式性能很低。
有索引:针对表中的age字段建立二叉树,此时进行数据查询会依据二叉树结构进行扫描,极大的提高了查询效率。
![]() | ![]() |
- 特点
优点 | 缺点 |
---|---|
提高数据检索的效率,降低数据库的IO成本 | 索引列占用空间 |
通过索引列对数据进行排序,降低数据排序的成本,降低CPU的消耗 | 索引降低更新(INSERT, UPDATE, DELETE)表的速度 |
索引结构
MySQL的索引实在存储引擎层实现的,不同的存储引擎拥有不同的索引结构。
索引结构 | InnoDB | MyISAM | Memory | 描述 |
---|---|---|---|---|
B+Tree索引 | 支持 | 支持 | 支持 | 最常见的索引类型,大部分引擎都支持B+树索引 |
Hash索引 | 不支持 | 不支持 | 支持 | 底层数据结构是用哈希表实现的,只有精度匹配索引列的查询才有效,不支持范围查询 |
R-Tree索引(空间索引) | 不支持 | 不支持 | 支持 | 空间索引是MyISAM引擎的一个特殊索引类型,主要用于地理空间数据类型,通常使用较少 |
Full-text索引(全文索引) | 5.6版本后支持 | 支持 | 不支持 | 一种通过建立倒排索引的结构,快速匹配文档的方式。类似Lucene, Solr |
-
二叉树
缺点:
1. 顺序插入时会形成一个链表,查询性能大大降低。(可以用红黑树解决)
2. 数据量大的情况下,层级较深,检索速度慢。 -
B-Tree(多路平衡查找树)
B-Tree的叶子节点和非叶子节点都会存放数据,一旦节点存储的key数量达到最大度数,中间元素就会向上分裂。以一棵最大度数(max-degree)为5的B-Tree为例 (每个节点最多存储4个key,5个指针)
数据结构可视化构建网站:https://www.cs.usfca.edu/~galles/visualization/Algorithms.html -
B+Tree(多路平衡查找树)
B+Tree是B-Tree的变种,非叶子节点仅仅起到索引数据的作用,叶子节点涵盖所有数据,且会形成一个单向链表。以一棵最大度数(max-degree)为4的B+Tree为例
-
Hash
Hash索引就是采用一定的Hash算法,将键值换算成新的Hash值映射到对应的槽位上,然后存储到Hash表中。如果两个(或多个)键值映射到一个相同的槽位上,数据存储就产生了Hash冲突,可以通过链表来解决。
特点:
1. Hash索引只能对等比较(=,in),不支持范围查询
2. 无法利用索引完成排序
3. 查询效率高 -
思考:为什么InnoDB存储引擎选择使用B+Tree索引结构?
1. 相比较二叉树索引,B+Tree的数据层级更少,搜索效率更高;
2. 相比较B-Tree索引,每个节点都会保存数据,这样导致一页中存储的键值对减少,指针也减少,同样存储数据,B-Tree需要更大的深度,效率降低。
3. 相比较Hash索引,Hash索引只适用于等值匹配,不适用于范围匹配。
索引分类
分类 | 含义 | 特点 | 关键字 |
---|---|---|---|
主键索引 | 针对表中主键创建的索引 | 默认自动创建,唯一 | PRIMARY |
唯一索引 | 避免同一个表中某字段的值重复 | 不唯一 | UNIQUE |
常规索引 | 快速定位特定数据 | 不唯一 | |
全文索引 | 全文索引查找的是文本中的关键词,而不是比较索引中的值 | 不唯一 | FULLTEXT |
在InnoDB存储引擎中,根据索引的存储形式,可以分为以下两种
分类 | 含义 | 特点 |
---|---|---|
聚集索引(Clustered Index) | 将数据与索引一起存储,索引结构的叶子节点保存行数据 | 必须且唯一 |
二级索引(Secondary Index) | 将数据与索引分开存储,索引结构的叶子节点关联对应的主键 | 不唯一 |
聚集索引选取规则:
1. 如果表中存在主键,主键索引就是聚集索引。
2. 如果表中不存在主键,则将第一个唯一索引作为聚集索引。
3. 如果表中没有主键,也没有唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索引。
索引语法
# 创建索引
CREATE [UNIQUE|FULLTEXT] INDEX index_name ON table_name ( index_col_name,... );
# 查看索引
SHOW INDEX FROM table_name;
# 删除索引
DROP INDEX index_name ON table_name;
SQL性能分析
-
SQL执行频率
MySQL客户端连接成功后,通过show [session|global] status命令可以提供服务器状态信息。通过如下指令,可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次:// 总共有7个下划线 SHOW [SESSION|GLOBAL] STATUS LIKE 'Com_______';
-
慢查询日志
慢查询日志记录了所有执行时间超过指定参数(long_query_time,,单位:秒,默认10秒)的所有SQL语句的日志。// 查看开启情况 SHOW variables LIKE 'slow_query_log';
MySQL的慢查询日志默认没有开启,需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息:
# 开启MySQL慢查询开关 slow_query_log = 1 # 设置慢查询日志的时间为2秒,SQL语句执行时间超过2秒,就会被视为慢查询,记录慢查询日志。 long_query_time = 2
-
profile详情
show profiles能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。通过have_profiling参数能够看到当前MySQL是否支持profile操作:SELECT @@have_profiling;
默认profiling是关闭的,可以通过set语句在session/global级别开启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;
-
explain执行计划
EXPLAIN或者DESC命令获取MySQL如何执行SELECT语句的信息,包括在SELECT语句执行过程中表如何连接和连接的顺序:# 直接在select语句之前加上关键字explain/desc EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;
- Id
select查询的序列号,表示查询中执行select子句或者是操作表的顺序(id相同,执行顺序从上到下;id不同,值越大越先执行) - select_type
表示SELECT的类型,常见的取值有SIMPLE(简单表)、PRIMARY(主查询,即外层的查询)、UNION(UNION中的第二个或者后面的查询语句)、SUBQUERY(SELECT/WHERE之后包含的子查询)等 - type
表示连接类型,性能由好到差的连接类型为NULL、system、const、eq_ref、ref、range、index、all - possible_key
显示可能应用在表上的索引,一个或多个 - key
实际使用的索引,如果为NULL,则没有使用索引。 - key_len
表示索引中使用的字节数,该值为索引字段最大可能长度,并非实际长度,在不损失精确性的前提下,长度越短越好。 - rows
MySQL认为必须要执行查询的行数,在InnoDB引擎的表中rows是一个估计值。 - filtered
表示返回结果的行数占需读取行数的百分比,filtered值越大越好。
- Id
索引使用
- 验证索引效率
在未建立索引之前,执行如下SQL语句,查看SQL的耗时。
- 最左前缀法则
最左前缀法则指查询从索引最左列开始,并且不跳过索引中的列。联合索引符合最左前缀法则。如果跳跃某一列,则索引将部分失效(后面的字段索引失效)。
- 范围查询
联合索引中出现">“、”<“范围查询,范围查询右侧的列索引会失效,此时将”>“、”<“改成”>=“、”<=",右侧索引就不会失效。
- 索引列运算
对索引字段进行运算,索引将失效。 - 字符串不加引号
使用字符串类型字段时,不加引号索引将失效。
- 模糊查询
如果字段中间或尾部使用模糊匹配,索引不会失效。如果头部使用模糊匹配,索引失效。
- or连接
“A or B”,如果条件A所在的列有索引,条件B所在的列没有索引,那么条件A所在的列的索引不会使用。
- 数据分布影响
如果MySQL评估使用索引比全表更慢,则不适用索引。
- SQL提示
SQL提示是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优化操作的目的。- use index:
explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';
- ignore index:
explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';
- force index:
explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';
- use index:
- 覆盖索引
覆盖索引指一条查询语句在查询的过程中使用了索引,并且查询需要返回的列和字段值在该索引中已经全部找到。尽量使用覆盖索引,减少select *,因为非索引字段有时需要回表查询。
- 前缀索引
当字段类型为字符串(varchar,text等)时,有时候需要索引很长的字符串,这会让索引变得很大,查询时浪费大量的磁盘IO,影响查询效率。此时可以只将字符串的一部分前缀建立索引,这样可以节约索引空间,提高检索效率。- 语法
# 提取前n个字符构建索引 create index idx_xxx on table_name(column(n));
- 前缀长度
根据索引的选择性决定,选择性指得是不重复的索引值(基数)和数据表的记录总数的比值,索引选择性越高则查询效率越高,唯一索引的选择性是1,这是最好的索引选择性,性能也最好。- 公式
select count(distinct substring(your_para,1,n) / count(*) from your_table;
- 公式
- 语法
- 单列索引与联合索引
- 单列索引:一个索引只包含单个列
- 联合索引:一个索引包含多个列
在业务场景中,如果存在多个查询条件,考虑针对于查询字段建立索引时建议建立联合索引。
注:多条件联合查询时,MySQL优化器会评估哪个字段的索引效率更高,选择该索引完成本次查询
索引设计原则
- 针对于数据量大且查询比较频繁的表建立索引。
- 针对常作为查询条件(where)、排序(order by)、**分组(group by) **操作的字段建立索引。
- 尽量选择区分度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高。
- 如果是字符串类型的字段,字段的长度较长,可以针对字段的特点建立前缀索引。
- 尽量使用联合索引,减少单列索引,很多情况下查询时联合索引可以覆盖索引,节省存储空间,避免回表,提高查询效率。
- 注意控制索引的数量。因为索引越多,维护索引结构的代价也越大,会影响增删改的效率。
- 如果索引列不能存储NULL值,在创建表时使用NOT NULL约束。当优化器知道每列是否包含NULL值时,它可以更好地确定哪个索引能最有效地查询信息。