关于MySQL优化的思考一【存储引擎、索引】

对于SQL优化，今天我们先来看下基本知识：

• 存储引擎，了解MySQL的不同存储引擎的特性和适用场景，可以帮助你在数据库设计和应用开发中做出明智的决策。
• 索引，当表没有索引时，查询数据可能是全表查询；当创建索引后，先查索引，根据索引检索到数据，提供获取数据的效率。如何建立索引至关重要。

1 存储引擎

1.1 MySQL体系结构层

• 连接层，该层是客户端和连接服务，主要完成类似于连接处理、授权认证等
• 服务层，要完成大多数核心服务功能，如SQL接口，并完成缓存的查询，SQL的分析和优化，部分内置函数的执行。所有跨存储引擎的功能也在该层实现，如过程、函数等
• 引擎层，存储引擎负责数据的存储和提取，服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能，可以根据自己的需要，选择合适的存储引擎
• 存储层，将数据存储在文件系统之上，并完成与存储引擎的交互

1.2 存储引擎简介

存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎基于表，可以以表的维度来进行指定。

查看当前表的存储引擎

-- 查看建表语句，查看存储引擎，默认是InnoDB
show create table emp;

新建表时指定存储引擎

create table 表名(
  字段 字段类型 [comment 字段注释]
  ...
  
)engine=innodb [comment 表注释];

查看当前数据库支持的存储引擎

show engines;

1.3 存储引擎特点

1.3.1 InnoDB

介绍
- InnoDB是一种兼顾高可靠性和高性能的通用的存储引擎，在MySQL5.5之后，作为MySQL的默认存储引擎
特点
- DML操作（增删改）遵循ACID模型，支持事务
- 行级锁，提高并发访问性能
- 支持外键foreign key约束，保证数据的完整性和正确性
文件
- xxx.idb：xxx代表表名，InnoDB存储引擎的每张表都会对应这样的一个表空间文件，存储该表的表结构（frm，sdi）、数据和索引

1.3.2 MyISAM

介绍
- MyISAM是MySQL早期默认的存储引擎
特点
- 不支持事务，不支持外键
- 支持表锁，不支持行锁
- 访问速度快
文件
- xxx.sdl：存储表结构信息
- xxx.MYD：存储数据
- xxx.MYI：存储索索引

1.3.3 Memory

介绍
- Memory引擎的表数据是存储在内存中的，由于受到硬件问题、或断电问题的影响，只能将这些表作为临时表或者缓存表使用
特点
-内存存放
- hash索引
文件
- xxx.sdi：存储表结构信息

1.4 存储引擎选择

在选择存储引擎时，需要根据应用系统的特点选择合适的存储引擎，对于复杂的应用系统，还可以根据实际情况选择多种存储引擎进行组合使用。

InnoDB：是MySQL的默认存储引擎，支持事务、外键。如果应用对事务的完整性有比较高的要求，在并发场景下要求数据一致性，数据操作除了插入和查询外，还包含很多的更新、删除操作，所有InnoDB存储引擎是好的选择
MyISAM：如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高。但实际场景会使用NoSQL
Memory：将所有的数据保存到内存中，访问速度快，通常用于临时表及缓存。缺陷是对表的大小有限制，太大的表无法缓存到内存中，而且无法保障数据的安全性。实际场景中使用NoSQL（Redis）

2 索引

索引（index），是帮助MySQL高效获取数据的数据结构（有序）。当表没有索引时，查询数据可能是全表查询；当创建索引后，先查索引，根据索引检索到数据，提供获取数据的效率。

2.1 索引的优缺点

优点	缺点
提高数据检索的效率，降低数据库的IO成本	索引列也要占用空间
通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗	索引大大提高了查询效率，同时也降低更新表的速度，如对表进行insert、update、delete时，效率降低

2.2 索引结构

MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构。

B+Tree索引，是常见的索引类型，大部分存储引擎都支持B+树索引，如常见的InnoDB、MyISAM、Memory存储引擎
Hash索引，底层数据结构是用哈希表实现的，只有精确匹配索引的查询才有效，不支持范围查询
R-tree（空间索引），空间索引是MyISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，很少用
Full-tree（全文索引），是一种通过建立倒排索引，快速匹配文档的方式，类似于Lucene、Solr、ES

二叉树数据结构

左侧的叶子节点小于父节点

二叉树在顺序插入时，会形成一个链表，查询性能大大降低，大数据量情况下，层级较深，检索速度慢。红黑树，平衡二叉树，可以解决形成链表，但是仍然有大数据量情况下，层级较深，检索速度较慢的问题。

B-Tree（多路平衡查找树）以一棵最大度数（max-degree）为5（5阶）的b-Tree为例（每个节点最多存储4个key，5个指针），可在https://www.cs.usfca.edu/\~galles/visualization/BTree.html上查看B-Tree数据结构

B+Tree的特点

所有的元素都会出现在叶子节点
上边的分页节点，只起到索引的作用，叶子节点用来存放数据
所有的叶子节点形成了一个单向链表

以一棵最大度数为4的B+Tree为例，

可在https://www.cs.usfca.edu/\~galles/visualization/BPlusTree.html上查看数据结构

MySQL索引数据结构对经典的B+Tree进行了优化，在原来B+Tree的基础上，增加了一个指向相邻子节点的链表指针，就形成了带有顺序的B+Tree，提高区间访问的性能。

Hash结构，哈希索引就是采用一定的hash算法，将键值换成新的hash值，映射到对应的槽位上，然后存储在hash表中

hash索引只能用于对等比较（=，in），不支持范围查询（between，>，<，...）
无法利用索引完成排序操作
查询效率高，通常只需要一次检索就可以了，效率通常要高于B+Tree索引

为什么InnoDB存储引擎使用B+Tree索引结构

相对于二叉树，层级更少，搜索效率高
对于B-Tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针也就减少，要同样保存大量数据，只能增加树的高度，导致性能降低
相对于Hash索引来说，B+Tree支持范围匹配和排序操作

2.3 索引分类

主键索引，针对表中的主键建立的索引，只能有一个，primary key
唯一索引，可以有多个，unique
常规索引，可以有多个，快速定位特定数据
全文索引，全文检索查找的是文本中的关键词，而不是比较索引中的值，可以有多个，fulltext

在InnoDB中的分类

聚集索引（Clustered index），将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据，必须有，且只有一个
二级索引（Second Index），将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键，可以存在多个

聚集索引的选取规则

如果存在主键，主键索引就是聚集索引
如果没有主键，将使用第一个唯一索引作为聚集索引
如果没有主键，也没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

聚集索引和二级索引的区别

聚集索引下挂的是行数据
二级索引下挂的是数据的id

回表查询

二级索引进行查询到ID
通过ID进行聚集索引查询到对应的数据

如下示例：

-- user 表中，id为主键，并且给name增加了索引

-- 该查询，可直接使用聚集索引（id为主键）进行查询

select * from user where id = 10;

-- 该查询，需要先使用二级索引，然后回表，使用聚集索引查询

select * from user where name = '小明';

InnoDB主键索引的B+Tree高度为多高？

假设，一行数据大小为1k，一页中可以存储16行这样的数据，InnoDB的指针占用6个字节的空间，主键即使为bigint，占用字节数为8。由于每页的大小为16K。

高度为2：即存储的行数据为117116 = 18736，n*8+(n+1)6=161024，算出的n约为1170
- 即存储的行数据为1171*16 = 18736
高度为3：1171117116=21939856
如果表中数据超过几千万了，就需要考虑分库分表等优化方式了

2.4 索引语法

创建索引

create [unique|fulltext] index index_name on table_name(字段1,字段2,...);

查看索引

show index from table_name;

删除索引

drop index index_name on table_name;

-- 创建数据库
CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `age` int NOT NULL,
  `city` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
);

-- 创建索引
create index index_name on user(name);

-- 查看索引
show index from user;

-- 创建索引
create index index_name_age_city on user(name,age,city);

-- 删除索引
drop index index_name_age_city on user;

2.5 索引使用法则

2.5.1 最左前缀法则

如果索引了多列（联合索引），要遵循最左前缀法则。最左前缀法则指：查询从索引的最左列开始，并不跳过索引中的列。如果跳跃某一列，索引将部分失效（后面的字段索引失效）

比如在user表中，创建的索引是id+name+age

可以使用到索引的情况
- 需要查询的列为id
- 需要查询的列为id+name
不能使用多索引的情况
- 需要查询的列为name+age

注意：经测试，发现MySQL8.0的版本上索引都没有失效！！！

2.5.2 范围查询

联合索引总，出现范围查询（<，>），范围查询右侧的列索引失效

-- 即city的这个列索引会失效
explain select * from user where name='夏明' and age > 30 and city ='北京';

-- 在>=、<=的查询中，city的列索引不会失效
explain select * from user where name='夏明' and age >= 30 and city ='北京';

2.5.3 索引列上运算会索引失效

不要在索引列上进行运算操作，索引将失效

create index index_age on user(age);


explain select * from user where substr(user.age,1,1)='3';

2.5.4 字符串不加引号会索引失效

字符串类型字段使用时，不加引号，索引将失效

create index index_age on user(name,age,status);

-- 可以使用索引
explain select * from test.user where name='夏明' and age = 30 and status ='1';

-- 部分索引失效
explain select * from test.user where name='夏明' and age = 30 and status =1;

2.5.5 模糊查询

如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配的话，索引会失效。

create index index_name on test.user(name);

explain select * from test.user where user.name like '张%';

-- 索引失效
explain select * from test.user where user.name like '%三';

-- 索引失效
explain select * from test.user where user.name like '%三%';

2.5.6 or连接的条件

用or分割开的查询条件，如果or的一侧没有索引（前边有后边没有；前边没有后边有），那索引会失效

-- 只有id为索引，使用or连接查询时，索引失效
explain select * from test.user where id = 1 or name='夏明';

2.5.7 数据分布影响

如果MySQL评估使用所有会比全表扫描还慢，则不会使用索引

create index index_age on test.user(age);

-- 由于所有的数据中age大于10，
explain select * from test.user where age >= 10;


-- 修改条件后，就使用到了索引
explain select * from test.user where age >= 30;

2.5.8 给引擎提示

提示存储引擎使用哪个索引:

use index
ignore index
force index

-- 创建2个索引
create index index_name_age_city on user(name,age,city);

create index index_name on user(name);

explain select * from test.user where name='夏明';

-- 建议使用索引
explain select * from test.user use index (index_name) where name='夏明';
-- 忽略使用索引
explain select * from test.user ignore index (index_name) where name='夏明';
-- 强制使用索引
explain select * from test.user force index (index_name) where name='夏明';

2.5.9 覆盖索引

尽量使用覆盖索引（查询使用了索引，并且查询的字段包含索引字段），减少使用select(*) Extra中的信息

using index condition：查询中使用了索引，但是需要回表查询数据
using where; using index：查询中使用了索引，并且查找的字段在索引上都有，不需要回表查询数据

2.5.10 单列索引和联合索引

单列索引：即一个索引只包含单个列
联合索引：即一个索引包含了多个列

实际的业务场景中，如果存在多个查询，考虑针对于查询字段建立索引时，建议建立联合索引多条件查询时，MySQL优化器会评估哪个字段的索引效率更高，会选择该索引完成本次查询

2.6 索引设计原则

针对于数据量较大，且查询比较频繁的表建立索引
针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引
尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高
如果是字符串类型的的字段，字段的长度很长，可以针对字段的特点，建立前缀索引
尽量使用联合索引，减少单例索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询速度
要控制索引的数量，索引并不是越多越好，索引越多，维护索引结构的代价就越大，会影响增删改的效率
如果索引列不能存储null值，在创建表的时候将就使用not null来约束。当优化器知道每列是否包含null值时，它可以更好的确定那个索引最有效