MySQL系列(六)--索引优化

　　在进行数据库查询的时候，索引是非常重要的，当然前提是达到一定的数据量。索引就像字典一样，通过偏旁部首来快速定位，而不是一页页

的慢慢找。

　　索引依赖存储引擎层实现，所以支持的索引类型和存储引擎相关，同一种索引底层实现在不同存储引擎也是不一样的

　　本文基于MySQL8.0版本，关于explain用法，可以参考：MySQL高级 之 explain执行计划详解

创建索引语法：

　　CREATE TABLE table_name[col_name data_type]

　　[UNIQUE|FULLTEXT|SPATIAL]

　　[INDEX|KEY]

　　[index_name](col_name[length])

　　[ASC|DESC]

参数：

　　1、UNIQUE、FULLTEXT和SPATIAL为可选参数，分别表示唯一索引、全文索引和空间索引

　　2、INDEX和KEY为同义词，二者作用相同，用来指定创建索引

　　3、col_name为需要创建索引的字段列，该列必须从数据表中该定义的多个列中选择

　　4、index_name为指定索引的名称，为可选参数，如果不指定则MySQL默认col_name为索引

　　5、length为可选参数，表示索引的长度，只有字符串类型的字段才能指定索引长度，如果数据列很长的话，MySQL不允许把整列作为索引

　　6、ASC或DESC指定升序或者降序的索引值存储

主键：主键索引是特殊的唯一索引，不能为null，建表时指定主键，只能有一个。

唯一索引：索引列的值必须唯一，包含联合索引，允许为null。

一般索引：最普通的索引，没有限制，相对于前两种效率最差。

全文索引：用于全文搜索，V5.7版本之后，MyIsam和InnoDB支持，只能用于char、varchar、Text列

除了建表时创建索引，还有两种方式：

1、Alter  TABLE table_name ADD PRIMARY KEY (column_name)/UNIQUE  [indexName] (column_name)/INDEX index_name (column_name)/FULLTEXT (column_name)

2、CREATE UNIQUE INDEX index_name/INDEX index_name ON table_name (column_name)　　不适用于primary key和FULLTEXT

索引分类：

1、B-tree索引：除了archive以外的存储引擎，都支持

使用B+树的数据结构实现来存储数据，能够加快数据的查询速度，从索引的根节点开始往下搜索

B-tree索引的数据是顺序存储的，所以适合范围查找

使用场景：

　　1、全值匹配的查询，例如：id='1001'

　　2、匹配最左前缀的查询，例如现在把id和name建立一个联合索引，这时候查询id='1001'可以使用到联合索引，因为id为这个索引最左字段，

但是如果通过name进行筛选，就无法用到联合索引

　　3、匹配列前缀查询，例如：id like '100%'也可以用到联合索引

　　4、匹配范围值的查询，例如id < '1001' and id > '1010'

　　5、精确匹配左前列并范围匹配另一列

　　6、值访问索引的查询(覆盖索引)

总结：对于联合索引，MySQL从左向右匹配知道遇到范围查询(>,<,between,like)就会停止匹配，后面的列就无法用索引

个人使用MySQL8.0版本，测试发现范围匹配照样可以使用索引

使用限制：

　　1、不使用索引最左列的查询，无法使用到联合索引

　　2、使用索引时不能跳过索引中的列

　　3、not in和<>无法使用索引

　　4、索引中有某个列使用了范围查找，则右边的所有列都无法使用索引

PS：不仅可以在where查询中使用，也可以使用在order by和group by中

2、Hash索引：

Memory存储引擎默认的索引，InnoDB也有Hash索引，这是InnoDB自动建立

Hash索引是基于Hash表实现的，对于Hash索引中所有列，存储引擎为每一列计算一个hash值，hash索引存储的就是hash码

理论上，效率还是好于B树索引，但是其使用限制太多了

使用限制：

　　通过hash索引找到对应的行，然后对行的数据进行读取，进行两次查找

　　无法用于避免数据的排序操作

　　无法使用部分索引键的查询

　　只有查询条件精确匹配Hash索引的所有列，才能使用Hash索引，不能是范围匹配和模糊匹配

　　可能产生hash冲突，不适合选择性很差的列，例如性别。

选择性：不重复的索引值和表的记录数的比值

　　比值越高索引的效率越好，因为选择性高的索引可以在查找时过滤掉更多的行，唯一索引的值是1，这是性能最好的

Innodb也有一个特殊的自适应哈希索引(adaptive hash index)

3、创建自定义哈希索引：

　　在B-Tree索引的基础上创建伪哈希索引，使用B-Tree进行查找，但是 不是使用键本身而是hash值进行查找，只需要在where条件中手动指定

hash函数，记住不要使用SHA1()/MD5()

4、空间数据索引(R-Tree)：

　　MyISAM支持，用于存储地理数据GPS数据，V5.7之后，InnoDB也支持了。

5、全文索引：

　　它是查找文本中的关键词，而不是直接比较索引中的值，全文索引和其它索引的匹配方式完全不同，不适用于where条件操作

6、聚簇索引：不是一种单独的索引类型，而不是一种数据存储方式

　　数据行存储在索引的叶子页，"聚簇"表示数据行和相邻的键值存储在一起，因为无法把数据行存放在两个地方，所以一个表只能有一个聚簇索引

　　对于Innodb的聚簇索引，Innodb通过主键聚集数据，如果没有定义主键，Innodb会选择一个唯一的非空索引代替，节点页只包含了索引页，叶子

页包含了全部数据，索引列包含了整数值

　　对于Innodb来说，主键使用AUTO_INCREATMENT比UUID要好，因为Innodb更适合按照主键顺序插入数据，高并发之下，自增长可能导致锁竞争

，可以重新设计表，或者使用innodb_autoinc_lock_mode参数配置，如果MySQL版本不支持，可以进行升级

索引的优点：

　　大大减少存储引擎要扫描的数据量

　　索引可以帮助我们进行排序以避免使用临时表，B-tree索引不需要进行数据排序

　　索引可以把随机I/O变成顺序I/O

索引带来的消耗：

　　增加写操作的成本，在对数据数据进行修改的时候，需要更新索引，所以索引越多，写入的越慢。所以，InnoDB有一层插入缓存，将多次写入

合并为一次写入

　　增加查询优化器的选择时间，同一个查询如果有很多索引可以选择，会导致查询优化器选择的时间变长

无法使用的场景：

　　内存无法使用，只有使用键值的索引才能使用

　　查询使用太多列的查询，如果索引中的数据太大了，也没啥使用必要

　　使用%%的like查询

PS：过多的索引对写、读的效率都是有影响的

索引优化：

1、索引列不能使用表达式或函数

例如：

　　where id +1 = 5;

　　SELECT * FROM temp WHERE TO_DAYS(date1)-TO_DAYS(current_date) > 30

优化：

　　where date1 > date_add(current_date,interval 30 day)

2、前缀索引和索引列的选择性

　　create index index_name on table(col_name(n))

　　索引很长的字符列（很长的varchar、text、blob），必须使用前缀索引（MyISAM 727字节，Innodb 1000字节），因为MySQL不允许索引这些

列的完整长度，使用前面所说的伪哈希索引是不行的，通常是索引开始的部分字符，可以节省索引空间，提高索引效率，但是会降低索引的选择性

所以需要在前缀索引的大小和选择性之间找到平衡

3、联合索引：很多列都建立索引不如建立联合索引

在多个单独列建立独立索引大多数情况不能提高MySQL查询性能，因为需要更多地内存和磁盘IO

　　1、当服务器对多个索引做相交操作（多个and）的时候，通常需要一个包含多个列的多列索引，而不是多个独立的单独索引

　　2、多个or（联合操作），会消耗大量CPU和内存资源在算法的缓存、排序和合并操作上，这种情况下，还可能有查询的并发性，还不如没有

索引，使用union

　　3、如果在explain中看到索引合并，就要检查一下查询和表结构。可以通过optimizer_switch来关闭索引合并功能，也可以使用ignore index

来让优化器忽略掉某些索引

如何选择索引列的顺序：在不考虑排序和分组的情况下

　　1、经常使用的列放在最左边，因为索引列是按照从左到右去使用的

　　2、选择性高的列优先

　　3、宽度小，意味着每一页的数据更多，磁盘IO消耗更少

4、覆盖索引：

　　如果一个索引包含、覆盖所需要查询的列的值，就称为"覆盖索引"

优点：

　　可以优化缓存，减少磁盘IO操作

　　因为B-tree索引可以减少随机IO，变随机IO访问为顺序IO操作，有利于数据的查询速度

　　避免InnoDB索引的二次查询，这点和Hash索引不同

　　避免MyISAM表进行系统调用，因为MySQL只是缓存索引的信息，数据要依赖操作系统缓存，所以访问数据的时候，需要进行一次系统调用，而

系统调用的性能通常不好

覆盖索引的限制：

　　存在存储引擎不支持覆盖索引，Memory

　　hash、全文、空间索引都不能做覆盖索引，只能使用B-Tree索引做覆盖索引

　　查询中使用太多的列，只有索引的大小远远小于数据本身才能发挥索引的作用

　　使用了like '%****%'这种双百分号的查询，因为存储引擎底层的API限制的，只能提取数据行的值并加载内存中，然后在内存中进行where过滤

例如：

CREATE TABLE `house_detail` (
  `id` bigint(11) NOT NULL AUTO_INCREMENT,
  `description` varchar(255) DEFAULT NULL COMMENT '详细描述',
  `layout_desc` varchar(255) DEFAULT NULL COMMENT '户型介绍',
  `traffic` varchar(255) DEFAULT NULL COMMENT '交通出行',
  `round_service` varchar(255) DEFAULT NULL COMMENT '周边配套',
  `rent_way` int(2) NOT NULL COMMENT '租赁方式',
  `address` varchar(32) NOT NULL COMMENT '详细地址 ',
  `subway_line_id` bigint(11) DEFAULT NULL,
  `subway_line_name` varchar(32) DEFAULT NULL COMMENT '附近地铁线名称',
  `subway_station_id` bigint(11) DEFAULT NULL,
  `subway_station_name` varchar(32) DEFAULT NULL COMMENT '地铁站名',
  `house_id` bigint(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_on_house_id` (`house_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=39 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci　

查询如下：EXPLAIN SELECT house_id FROM house_detail WHERE house_id = 15;

可以在Extra中看到Using index，还有使用的索引名称

如果是EXPLAIN SELECT house_id FROM house_detail WHERE house_id LIKE '%1%';

我们看到Using where和Using index

PS：版本越高可能存在更多的内部优化

使用索引来优化查询：

1、使用索引扫描来优化排序

MySQL实现排序的方式：通过排序操作/按照索引顺序扫描数据

索引优化排序的要求：

　　1).索引的列顺序与order by子句的顺序一致

　　2).索引列的方向(升序、降序)和order by子句完全一致

　　3).多个表的关联查询中，order by中的字段全部在关联表的第一张表中

栗子一：

CREATE TABLE `rental` (
  `rental_id` int(11) NOT NULL AUTO_INCREMENT,
  `rental_date` datetime NOT NULL,
  `inventory_id` mediumint(8) unsigned NOT NULL,
  `customer_id` smallint(5) unsigned NOT NULL,
  `return_date` datetime DEFAULT NULL,
  `staff_id` tinyint(3) unsigned NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`rental_id`),
  UNIQUE KEY `rental_date` (`rental_date`,`inventory_id`,`customer_id`),
  KEY `idx_fk_inventory_id` (`inventory_id`),
  KEY `idx_fk_customer_id` (`customer_id`),
  KEY `idx_fk_staff_id` (`staff_id`)
) ENGINE=InnoDB AUTO_INCREMENT=39 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

EXPLAIN SELECT * FROM rental WHERE rental_date > '2005-01-01' ORDER BY rental_id;

栗子二：

EXPLAIN SELECT * FROM rental WHERE rental_date = '2005-01-01' ORDER BY inventory_id, customer_id;

EXPLAIN SELECT * FROM rental WHERE rental_date = '2005-01-01' ORDER BY inventory_id DESC, customer_id;

我们看到Using filesort，证明了第二条要求

栗子三：

EXPLAIN SELECT * FROM rental WHERE rental_date > '2005-01-01' ORDER BY inventory_id DESC, customer_id;

证明了：联合索引前面的列使用了范围查找，后面的列不能使用索引，所以使用的是filesort

2、使用hash索引来优化查询

　　前面有简单提过自定义Hash索引，B-tree索引的长度是有限制的，在列的长度过大的时候，只能使用前缀索引，但是会造成选择性变差，所以

在B-tree索引上建立Hash索引是一个解决方案

CREATE TABLE `rental` (
  `rental_id` int(11) NOT NULL AUTO_INCREMENT,
  `rental_date` datetime NOT NULL,
  `inventory_id` mediumint(8) unsigned NOT NULL,
  `customer_id` smallint(5) unsigned NOT NULL,
  `return_date` datetime DEFAULT NULL,
  `staff_id` tinyint(3) unsigned NOT NULL,
  `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `description` varchar(255) NOT NULL,
  `description_md5` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`rental_id`),
  UNIQUE KEY `rental_date` (`rental_date`,`inventory_id`,`customer_id`),
  KEY `idx_fk_inventory_id` (`inventory_id`),
  KEY `idx_fk_customer_id` (`customer_id`),
  KEY `idx_fk_staff_id` (`staff_id`),
  KEY `idx_md5` (`description_md5`),
  KEY `idx_description` (`description`)
) ENGINE=InnoDB AUTO_INCREMENT=39 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

EXPLAIN SELECT * FROM rental WHERE description_md5 = md5('this is food') AND description = 'this is food';

注意hash函数的选择，尽量不使用SHA1()/md5，这只是举例，可以选择CRC32()等其他函数。

原字段和hash处理的字段都要筛选，为了避免hash冲突对性能的影响

特点：

　　1、只能匹配键值的全职匹配的查询

　　2、索引大小取决于hash函数

3、利用索引来优化锁

Innodb使用的是行级锁，只有在修改行的时候，才会被加锁，索引就减少了锁定的行数，也加快了锁的释放

索引可以加快处理速度，也加快了锁的释放

如果没有索引，对表进行操作，使用排它锁，就会把整个表锁住，而使用了索引，只会锁住一行

CREATE TABLE actor(
	actor_id SMALLINT(5) UNSIGNED NOT NULL auto_increment,
	first_name VARCHAR(45) NOT NULL,
	last_name VARCHAR(45) NOT NULL,
	last_update timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
	PRIMARY KEY (actor_id)
)	ENGINE=InnoDB AUTO_INCREMENT=39 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
EXPLAIN SELECT * FROM actor WHERE last_name='tom' for UPDATE;
--在另一个会话中，执行下个语句，发现无法执行
EXPLAIN SELECT * FROM actor WHERE last_name='jerry' for UPDATE;

--如果把last_name列加上索引
CREATE INDEX idx_lastname ON actor(last_name);
EXPLAIN SELECT * FROM actor WHERE last_name='tom' for UPDATE;
--在另一个会话中，执行下个语句，发现就可以执行
EXPLAIN SELECT * FROM actor WHERE last_name='jerry' for UPDATE;

4、索引的维护和优化

1).删除重复索引

　　例如：id 主键primary key 主键索引unique key 单列索引index，这时候主键实际上就是一个非空的唯一索引

2).删除冗余索引：已经创建了索引，但是有联合索引包含了该列

　　例如：index(a) index(a,b)

　　primary key(id) index(b,id)

可以通过工具pt-duplicate-key-checker h=127.0.0.1查看冗余索引是否有存在的必要，可以saklia官网下载

3).删除很少或不会再被使用的索引

有SQL语句可以查看数据库的各个表的索引使用次数，这样就可以确定有些索引有没有存在的必要

SELECT
	object_schema,
	object_name,
	index_name,
	b.table_rows
FROM
	performance_schema.table_io_waits_summary_by_index_usage a
JOIN information_schema.TABLES b ON a.OBJECT_SCHEMA = b.table_schema
AND a.OBJECT_NAME = b.table_name
WHERE
	INDEX_NAME IS NOT NULL
AND COUNT_STAR = 0
ORDER BY
	OBJECT_SCHEMA,
	OBJECT_NAME;

　

4).更新索引的统计信息及减少索引碎片

重新生成索引的统计信息：analyze table table_name

MyISAM需要把统计信息保存在磁盘中，需要扫描所有的索引，会把表进行锁定

InnoDB是保存在内存中，生成的是估算值，不是百分百准确

通过optimize table table_name对表和索引进行维护，但是会锁表