Java性能调优专题之MySQL

前言

Java性能调优专题之MySQL（一）

---

一、索引的本质

索引是帮助MySQL高效获取数据的排好序的数据结构

二、MySQL索引数据结构选择

1.二叉树

对于单边增长的数据，对于提高查询效率没有任何帮助，因此不作考虑，如下图：

2.红黑树（二叉平衡树）

在数据量较大时，树的高度会很大，因此不作考虑，如下图：

上述二叉树结构所使用的数据结构绘图网站： Data Structure Visualizations

3.B树

B树的数据结构特点如下：

• 所有索引元素不重复
• 索引从左到右递增排列
• 每个索引都会存储相应的data
• 叶节点的指针为空
  

4.B+树

B+树的数据结构特点如下：

• 索引从左到右递增排列
• 非叶子节点不存储data，只存储索引
• 叶子节点包含所有的索引字段
• 叶子节点用指针连接，提高区间访问的性能

MySQL5.0之前使用的是B树索引，后优化为使用B+树索引

B+树相对于B树来说，最主要的区别是非叶子节点只存储索引，这样每个页中可以存放更多的索引，从而降低树的高度

MySQL中每个索引页的大小为16K，由于非叶子节点只存索引不存记录，所以按照一个索引10个字节的大小计算，大概可以存储1600个索引，第二层的每个索引页同理，假设叶子节点中每条数据的大小为1K，则每个叶子节点大概可以存储16条数据，则总的存储量=1600 X 1600 X 16，因此一个三层结构的B+树就可以存放千万级别的数据了

5.Hash索引

Hash索引的特点如下：

• 对索引的key进行一次hash计算就可以定位出数据存储的位置
• 会导致hash冲突问题
• 仅能满足 “=”，“IN”，不支持范围查询
• 很多时候Hash索引要比B+ 树索引更高效
  

三、常见数据引擎的索引实现

1.MyISAM

MyISAM的索引文件和数据文件是分离的(非聚集索引)，索引文件仅保存记录所在页的指针（物理位置），通过这些地址来读取页，进而读取被索引的行

MyISAM存储引擎在建表的时候，会创建3个文件：

• frm文件：存储表的定义，也就是表结构
• MYD文件：存储表的数据
• MYI文件：存储表的索引文件

2.InnoDB

InnoDB的主键索引，索引文件和数据文件是在一起的(聚集索引)，表数据文件本身就是按B+Tree组织的一个索引结构文件，并且聚集索引的叶节点包含了完整的数据记录

InnoDB存储引擎在建表的时候，会创建2个文件：

• frm文件：存储表的定义，也就是表结构
• ibd文件：存储表的索引和数据

因为索引和数据保存在同一个B+树中，因此聚簇索引的数据访问速度更快，并且在范围查询时，由于数据紧密相连，可以从更少的数据块中提取数据，节省了大量的IO操作

但是聚集索引的插入速度严重依赖于插入顺序，按主键的顺序插入时是最快的，否则会出现页分裂，严重影响性能，因此对于InnoDB我们一般都会定义一个自增的ID作为主键，不建议使用UUID或者MD5等作为主键

另外，InnoDB中的非主键索引并不是聚集索引，例如为c2列创建单值索引，则会针对c2列创建一个B+树，非叶子节点存储的是记录的c2列+页号，叶子节点存储的并不是完整的用户记录，而是c2列+主键这两个列的值，定位到对应的主键后，需要进行回表操作来获取数据

这里有个问题，为什么非主键索引结构叶子节点存储的是主键值？（数据一致性和节省存储空间）

针对联合索引，我们在使用时需要基于最佳左前缀法则：查询从索引的最左前列开始并且不跳过索引中的字段，这是基于联合索引底层的数据结构考虑的：

三、Explain详解

1.Explain概述

在 select 语句之前增加 explain 关键字 ，MySQL会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是执行这条SQL（注意如果 from 语句中包含子查询，仍会执行该子查询，并将结果放入临时表中）

2.Explain分析示例

官方文档参考： MySQL5.7 Reference

本次使用的示例表结构如下：

DROP TABLE IF EXISTS `actor`; 
CREATE TABLE `actor` (
  `id` int(11) NOT NULL,
  `name` varchar(45) DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `actor` (`id`, `name`, `update_time`) 
VALUES (1,'a','2017-12-22 15:27:18'), (2,'b','2017-12-22 15:27:18'), (3,'c','2017-12-22 15:27:18');

DROP TABLE IF EXISTS `film`;
CREATE TABLE `film` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `film` (`id`, `name`) 
VALUES (3,'film0'),(1,'film1'),(2,'film2');

DROP TABLE IF EXISTS `film_actor`;
CREATE TABLE `film_actor` (
  `id` int(11) NOT NULL,
  `film_id` int(11) NOT NULL,
  `actor_id` int(11) NOT NULL,
  `remark` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_film_actor_id` (`film_id`,`actor_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `film_actor` (`id`, `film_id`, `actor_id`) 
VALUES (1,1,1),(2,1,2),(3,2,1);

3.Explain的列信息

接下来逐个介绍explain中每个列的信息：

• id
  id的编号是select的序列号，有几个select就有几个id
id越大执行优先级越高，id相同则从上往下执行，id为NULL时最后执行
• select_type
  select_type表示对应行是简单查询（simple，查询不包括子查询和union）还是复杂查询 ，其中复杂查询又包括如下类型：
  • primary：复杂查询中最外层的select
  • subquery：包含在select中的子查询（不在from子句中）
  • derived：包含在from子句中的子查询，作为临时表使用

可以用下面这个例子来了解上述几种类型：

-- 关闭mysql5.7新特性对衍生表的合并优化
set session optimizer_switch='derived_merge=off';
explain select (select 1 from actor where id = 1) from (select * from film where id = 1) der;
-- 还原mysql5.7新特性对衍生表的合并优化
set session optimizer_switch='derived_merge=on';

上述explain语句的执行结果为：

• table
  table表示explain的一行正在访问哪个表，可以参考select_type中的举例
• type
  type表示关联类型或访问类型，即MySQL决定如何查找表中的行，从最优到最差依次为：system > const > eq_ref > ref > range > index > ALL，一般来说，我们需要保证查询语句达到range级别，最好达到ref
  • system/const：primary key或unique key的所有列与常数比较时会返回该值，其中system是const的特例，表里只有一条数据匹配时为system，否则为const
  • eq_ref：primary key或unique key索引的所有部分都被连接使用，最多只会返回一条符合条件的记录
  • ref：相比于eq_ref，不使用唯一索引，而是使用普通索引或者唯一索引的部分前缀和某个值相比较，可能会找到多个符合条件的行
  • range：范围扫描通常出现在 in, between , >= 等操作中，使用索引来检索给定范围的行
  • index：扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比ALL快一些
  • ALL：即全表扫描，扫描聚簇索引的所有叶子节点
• possible_keys
  possible_keys显示查询可能使用哪些索引来查找，在explain时可能出现possible_keys有值，而key显示NULL的情况，这种情况是因为表中数据不多，MySQL认为索引对此查询帮助不大，选择了全表查询
  如果该列是NULL，则表示本次查询没有相关的索引，在这种情况下，可以通过检查where子句来创造一个适当的索引提高查询性能
• key
  key显示MySQL实际采用哪个索引来优化对该表的访问
  如果没有使用索引，则该列是 NULL，如果想强制MySQL使用或忽视possible_keys列中的索引，则可以在查询中使用 force index和ignore index
• key_len
  key_len列显示了MySQL在索引里使用的字节数，通过这个值可以算出具体使用了索引中的哪些列
  可以用下面这个例子来了解key_len的使用逻辑

explain select * from film_actor where film_id = 2;

上述explain语句的执行结果为：

film_actor的联合索引 idx_film_actor_id 由 film_id 和 actor_id 两个int列组成，并且每个int是4字节，通过结果中的key_len=4可推断出查询只使用了第一个列film_id来执行查找

key_len的计算规则如下：

char(n)：如果存汉字长度就是3n字节
varchar(n)：如果存汉字则长度是3n + 2字节，加的2字节用来存储字符串长度，因为varchar是变长字符串
tinyint：1字节
smallint：2字节
int：4字节
bigint：8字节　　
date：3字节
timestamp：4字节
datetime：8字节
另外，如果字段允许为 NULL，需要1字节记录是否为 NULL

• ref
  ref列显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有：const（常量），字段名（如：film.id）
• rows
  rows列是MySQL估计要读取并检测的行数
• Extra
  Extra列展示的是额外信息，常见的一些重要值如下：
  • Using index：使用覆盖索引，覆盖索引一般针对的是辅助索引，整个查询结果只通过辅助索引就能拿到结果，不需要通过辅助索引树找到主键，再通过主键去主键索引树里获取其它字段值
  • Using where：查询的列未被索引覆盖，使用where语句来处理结果
  • Using filesort：用外部排序而不是索引排序，数据较小时从内存排序，否则需要在磁盘完成排序，这种情况下一般是要考虑使用索引来优化的

4.索引的最佳实践

示例表如下：

CREATE TABLE `employees` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  `position` varchar(20) NOT NULL DEFAULT '' COMMENT '职位',
  `hire_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间',
  PRIMARY KEY (`id`),
  KEY `idx_name_age_position` (`name`,`age`,`position`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8 COMMENT='员工记录表';

INSERT INTO employees(name,age,position,hire_time) VALUES('LiLei',22,'manager',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('HanMeimei', 23,'dev',NOW());
INSERT INTO employees(name,age,position,hire_time) VALUES('Lucy',23,'dev',NOW());

针对如下查询语句，查看其执行计划：

-- 1.全值匹配，下述3条语句都可以走上索引，但是key_len不同
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei';
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22;
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';

-- 2.最左前缀法则：查询从索引的最左前列开始并且不跳过索引中的列，下述第2、3条语句是走不上索引的
EXPLAIN SELECT * FROM employees WHERE name = 'Bill' and age = 31;
EXPLAIN SELECT * FROM employees WHERE age = 30 AND position = 'dev';
EXPLAIN SELECT * FROM employees WHERE position = 'manager';

-- 3.在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描
EXPLAIN SELECT * FROM employees WHERE name = 'LiLei';
EXPLAIN SELECT * FROM employees WHERE left(name,3) = 'LiLei';

-- 4.不能使用索引中范围条件右边的列
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 22 AND position ='manager';
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age > 22 AND position ='manager';

-- 5.尽量使用覆盖索引，减少 select * 语句
EXPLAIN SELECT name,age FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';
EXPLAIN SELECT * FROM employees WHERE name= 'LiLei' AND age = 23 AND position ='manager';

-- 6.使用不等于（！=或者<>），not in ，not exists 的时候无法使用索引会导致全表扫描
EXPLAIN SELECT * FROM employees WHERE name != 'LiLei';

-- 7.is null,is not null 一般情况下也无法使用索引
EXPLAIN SELECT * FROM employees WHERE name is null;

-- 8.like以通配符开头导致索引失效会变成全表扫描操作
EXPLAIN SELECT * FROM employees WHERE name like '%Lei';
EXPLAIN SELECT * FROM employees WHERE name like 'Lei%';
-- 解决like'%字符串%'索引不被使用的方法：使用覆盖索引，如下：
EXPLAIN SELECT name,age,position FROM employees WHERE name like '%Lei%';

-- 9.字符串不加单引号索引失效
EXPLAIN SELECT * FROM employees WHERE name = '1000';
EXPLAIN SELECT * FROM employees WHERE name = 1000;

-- 10.少用or或in，用它查询时，mysql不一定使用索引，mysql内部优化器会根据检索比例、表大小等多个因素整体评估是否使用索引
EXPLAIN SELECT * FROM employees WHERE name = 'LiLei' or name = 'HanMeimei';

-- 11.范围查询优化
给年龄添加单值索引
ALTER TABLE `employees` ADD INDEX `idx_age` (`age`) USING BTREE ;
explain select * from employees where age >=1 and age <=2000;

复核索引的使用总结：