MySQL调优与索引优化

前言

关于存储引擎以及索引优化也可以参考之前的文章 MySQL数据库与SQL优化，本篇是对MySQL数据库与优化的一个补充

一、MySQL存储引擎

1、查看存储引擎

1、查看当前MySQL提供的存储引擎

mysql> show engines;

2、查看数据库当前使用的存储引擎

mysql> show variables like '%storage_engine%';

3、查看数据库表所用的存储引擎

mysql> show create table user;

4、创建表指定存储引擎

create table table_name(
 column_namecolumn_type
)ENGINE=存储引擎名 DEFAULT CHARSET=UTF8;

5、修改表的存储引擎

alter table 表名 engine=存储引擎名

6、修改默认的存储引擎

在 windows 系统中 mysql 安装目录中的 my.ini 配置文件中修改；在 Linux 系统中 /etc/my.cnf 文件中。

default-storage-engine=存储引擎名

二、索引

1、分析慢的原因

1. 查询的数据过多，建议分库分表。

2. 关联了太多的表，太多的 join ，它的原理是用 A 表的每一条数据扫描 B 表的所有数据。

3. 没有充分利用到索引：

   索引针对 列 建立，但并不是每一列都建索引。

   索引也不是越多越好，当数据更新时，索引也会进行调整，很消耗性能。

   mysql 并不会把所有的索引都用上，只会根据其算法挑一个索引用，所以建准索引也很重要。

4. 服务器调优及各个参数的配置（缓冲、线程数等），调整 my.cnf 中的参数。

2、索引简介

索引（Index）是帮助MySQL高效获取数据的数据结构，是将数据排好序的快速查找的数据结构。

3、索引详解

在数据之外，数据库系统还维护着满足特定查找算法的数据结构 ，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

左边是数据表，一共有七条记录，最左边的是数据记录的物理地址

为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应的数据，从而实现快速检索出符合条件的数据。

二叉树弊端：二叉树很可能会发生两边不平衡的情况。

• B-TREE：会自动根据两边的情况自动调节，使两端无限趋近于平衡状态。可以使性能最稳定（MyISAM引擎使用的方式）；当插入修改操作多时，B-TREE会不断调整平衡，消耗性能。
• B+TREE：是InnoDB引擎所使用的索引。

一般来说索引本身也很大，不可能全部储存在内存中，因此索引往往以索引文件的形式存储在磁盘上。

我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引。 其中聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。

4、索引的优点

• 可以大大加快数据的检索速度，降低数据的IO成本，这也是创建索引的最主要的原因。
• 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
• 可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。
• 在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间，降低CPU的消耗。
• 通过使用索引，可以在查询的过程中，使用查询优化器，提高系统的性能。

5、索引的缺点

• 创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
• 索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间。如果要建立聚簇索引，那么需要的空间就会更大。
• 当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。
• 索引只是提高效率的一个因素，如果你的MySQL有大量数据量的表，就需要花时间研究建立最优秀的索引，或者优化查询语句。

6、索引的分类

• 主键索引：设定为主键后会自动建立索引

• 单值索引：即一个索引只包含单个列，一个表可以有多个单列索引。

• 唯一索引：索引列的值必须唯一，但允许有空值。

• 复合索引：即一个索引包含多个列。

7、操作索引的方式

1、建表时创建索引格式

create table 表名(
	字段名 数据类型 [完整性约束条件],
  	.....,
  	[UNIQUE | FULLTEXT | SPATIAL] INDEX | KEY
  	[索引名](字段名1 [(长度)][ASC | DESC]) [USING 索引方法]
);

说明：

UNIQUE：可选，表示索引为唯一性索引。

FULLTEXT：可选，表示索引为全文索引。

SPATIAL：可选，表示索引为空间索引。

INDEX 和 KEY：用于指定字段为 索引，两者选择其中之一就可以了，作用是一样的。

索引名：可选，给创建的索引取一个新名称。

字段名1：指定索引对应的字段的名称，该字段必须是建表时定义好的字段。

长度：可选，指索引的长度，必须是字符串类型才可以使用。

ASC:可选，表示升序排列。

DESC:可选，表示降序排列。

2、建表之后再创建索引

-- 方法一
ALTER TABLE 表名 ADD [UNIQUE | FULLTEXT | SPATIAL] INDEX | KEY [索引名] (字段名1 [(长度)] [ASC | DESC]) [USING 索引方法];
-- 方法二
CREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX 索引名 ON 表名(字段名) [USING 索引方法];

3、查看索引

SHOW INDEX FROM [table_name];
--  只在 MySQL 中可以使用 keys 关键字。
SHOW KEYS FROM [table_name]; 

4、删除索引

DROP INDEX [index_name] ON [table_name];
ALTER TABLE [table_name] DROP INDEX [index_name];
ALTER TABLE [table_name] DROP PRIMARY KEY;

5、ALTER四种添加索引的案例

-- 该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。
ALTER TABLE tbl_name ADD PRIMARY KEY (column_list);
-- 这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。
ALTER TABLE tbl_name ADD UNIQUE index_name (column_list);
-- 添加普通索引，索引值可出现多次
ALTER TABLE tbl_name ADD INDEX index_name (column_list);
-- 该语句指定了索引为 FULLTEXT ，用于全文索引
ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list);

8、索引结构

1、BTree索引

初始化说明：

一颗B树，浅蓝色的块称之为一个磁盘块，可以看到每个磁盘块包含几个数据项（深蓝色）和指针（黄色），如磁盘块1包含数据项17和35，包含指针P1、P2、P3，P1表示小于17的磁盘块，P2表示在17和35之间的磁盘块，P3表示大于35的磁盘块。

真实的数据存在于叶子节点即3、5、9、10、13、15、28、29、36、60、75、79、90、99

非叶子节点不存储真实数据，只存储指引搜索方向的数据项，如17、35并不是真正存在于数据表中。

查找过程：

如果要查找数据项29，那么首先会把磁盘块1由磁盘加载到内存，此时发生一次I/O，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的I/O）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次I/O，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次I/O，同时内存中做二分查找找到29，结束查询，总计三次I/O。

真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。

2、B+Tree索引

B+TREE 第二级的数据并不能直接取出来，只作索引使用。在内存有限的情况下，查询效率高于 B-TREE
B-TREE 第二级可以直接取出来，树形结构比较重，在内存无限大的时候有优势。

区别：

B+Tree与B-Tree 的区别：在内存有限的情况下，B+TREE 永远比 B-TREE好。无限内存则后者好。

• B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。(一次查询可能进行两次I/O操作)
• 在B-树中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而B+树中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看B-树的性能好像要比B+树好，而在实际应用中却是B+树的性能要好些。因为B+树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比B-树多，树高比B-树小，这样带来的好处是减少磁盘访问次数。尽管B+树找到一个记录所需的比较次数要比B-树多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中B+树的性能可能还会好些，而且B+树的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用B+树的缘故。

为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？

• B+树的磁盘读写代价更低，B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
• B+树的查询效率更加稳定，由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。

3、聚簇索引和非聚簇索引

聚簇索引：将数据存储与索引放在一起，找到索引也就找到数据。聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。

非聚簇索引：将数据存储于索引分开结构，索引结构的叶子节点指向了数据的对应行，MyISAM通过key_buffer把索引先缓存到内存中，当需要访问数据时（通过索引访问数据），在内存中直接搜索索引，然后通过索引找到磁盘相应数据，因此这也是速度慢的原因。

图示：左侧的索引就是聚簇索引，因为 数据行在磁盘的排列和索引排序保持一致

聚簇索引的优点：

• 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量 IO 操作。

聚簇索引的劣势：

• 对于MySQL数据库目前只有InnoDB数据引擎支持聚簇索引，而MyISAM并不支持聚簇索引。
• 由于数据物理存储排序方式只能有一种，所以每个Mysql的表只能有一个聚簇索引。一般情况下就是该表的主键。如果表中没有主键，InnoDB会选择一个唯一的非空索引代替，如果没有这样的索引，InnoDB会隐式定义一个主键来作为聚簇索引。
• 为了充分利用聚簇索引的聚簇的特性，所以InnoDB表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如uuid这种。

注：这也说明了主键索引为何采用自增的方式，业务需求有序，能使用到聚簇索引。

4、Full-Text全文索引

全文索引（也称全文检索）是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。

限制：

• mysql5.6.4以前只有MyISAM支持，5.6.4版本以后InnoDB才支持，但是官方版本不支持中文分词，需要第三方分词插件。5.7以后官方支持中文分词。
• 随着大数据时代的到来，关系型数据库应对全文索引的需求已力不从心，逐渐被 solr，elasticSearch等专门的搜索引擎所替代。

5、Hash索引

Hash索引只有Memory、NDB两种引擎支持，Memory引擎默认支持Hash索引，如果多个hash值相同，出现哈希碰撞，那么索引以链表方式存储。NoSql采用此中索引结构。

6、R-Tree索引

R-Tree在mysql很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有myisam、bdb、innodb、ndb、archive几种。相对于B-Tree，R-Tree的优势在于范围查找。

9、适合创建索引的情况

1. 主键自动建立唯一索引。
2. 在经常使用在 WHERE 子句中的列上面创建索引，加快条件的判断速度。
3. 查询中与其它表关联的字段，外键关系建立索引。
4. 在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的。
5. 在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间。
6. 在分组后面的字段有索引能大大提高效率。

10、不适合创建索引的情况

1. 表数据太少。
2. 经常增删改的表。
3. Where条件里用不到的字段不创建索引。
4. 数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。

三、性能分析之Explain

1、简介

Explain表示查看执行计划，使用Explain关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理SQL语句的，进而分析查询语句或是表结构的性能瓶颈。

2、作用

1. 查看表的读取顺序。
2. 查看哪些索引可以使用。
3. 查看数据读取操作的操作类型。
4. 查看哪些索引被实际使用。
5. 查看表与表之间的引用。
6. 查看每张表有多少行被物理查询。

3、使用

语法：

Explain + SQL语句

执行计划包含的信息：

4、各字段解释

1、id

id字段表示select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序。

三种情况：

1、id相同，表示执行顺序由上至下。

2、id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行。

3、id有相同也有不相同的，id如果相同，可以认为是一组，从上往下顺序执行，在所有组中，id值越大，优先级越高，越先执行

2、select_type

select_type表示每个表被查询的查询类型，主要是用于区别普通查询、联合查询、子查询等的复杂查询。

select_type取值说明：

• SIMPLE：简单的 select 查询，查询中不包含子查询或者 UNION。

• PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为Primary。

• DERIVED：在FROM列表中包含的子查询被标记为DERIVED(衍生)，MySQL会递归执行这些子查询，把结果放在临时表里。

• SUBQUERY：在SELECT或WHERE列表中包含了子查询。

• DEPENDENT SUBQUERY：在SELECT或WHERE列表中包含了子查询,子查询基于外层。

• UNCACHEABLE SUBQUREY：无法被缓存的子查询。

• UNION：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED。

• UNION RESULT：从UNION表获取结果的SELECT

3、table

table显示查询的数据来源于哪张表。

4、partitions

partitions表示分区表中的命中情况，非分区表，就为NULL。

5、type

type显示的是访问类型，是较为重要的指标。

结果值从最好到最坏依次是：

system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range(尽量保证) > index > ALL

system>const>eq_ref>ref>range>index>ALL

一般来说，得保证查询至少达到range级别，最好能达到ref。

type取值说明：

• system：表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计。

• const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快如将主键置于where列表中，MySQL就能将该查询转换为一个常量。

• eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描。

• ref：非唯一性索引扫描，返回匹配某个单独值的所有行，本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。

• range：只检索给定范围的行，使用一个索引来选择行。key 列显示使用了哪个索引一般就是在你的where语句中出现between、<、>、in、like等的查询，这种范围扫描索引比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。

• index：出现index是sql使用了索引但是没有通过索引进行过滤，一般是使用了覆盖索引或者是利用索引进行了排序分组。

• all：全表扫描，将遍历全表以找到匹配的行。

• index_merge：在查询过程中需要多个索引组合使用，通常出现在有 or 的关键字的sql中。

• ref_or_null：对于某个字段既需要关联条件，也需要null值得情况下。查询优化器会选择用ref_or_null连接查询。

• index_subquery：利用索引来关联子查询，不再全表扫描。

• unique_subquery：该联接类型类似于index_subquery，子查询中的唯一索引。

6、possible_keys

显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

7、key

实际使用的索引。如果为 NULL，则没有使用索引。查询中若使用了覆盖索引，则该索引和查询的select字段重叠

8、key_len

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。 key_len字段能够帮你检查是否充分的利用上了索引

9、ref

显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值。

10、rows

rows列显示MySQL认为它执行查询时必须检查的行数。越少越好

11、filtered

这个字段表示存储引擎返回的数据在server层过滤后，剩下多少满足查询的记录数量的比例，注意是百分比，不是具体记录数。

12、Extra

包含不适合在其他列中显示但十分重要的额外信息

extra取值说明：

• Using filesort：说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序”。

• Using temporary：使了用临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。

• USING index：表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！如果同时出现using where，表明索引被用来执行索引键值的查找；如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找。利用索引进行了排序或分组。

• Using where：表明使用了where过滤。

• Using join buffer：使用了连接缓存。

• impossible where：where子句的值总是false，不能用来获取任何元组。

• select tables optimized away：在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

13、覆盖索引三种简单解释

• 就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。

• 索引是高效找到行的一个方法，当能通过检索索引就可以读取想要的数据，那就不需要再到数据表中读取行了。如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫做覆盖索引。

• 是非聚集组合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段，也即，索引包含了查询正在查找的所有数据）。

四、优化案例

1、单表索引优化

1、建表sql

CREATE TABLE IF NOT EXISTS `article` (
`id` INT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
`author_id` INT(10) UNSIGNED NOT NULL,
`category_id` INT(10) UNSIGNED NOT NULL,
`views` INT(10) UNSIGNED NOT NULL,
`comments` INT(10) UNSIGNED NOT NULL,
`title` VARBINARY(255) NOT NULL,
`content` TEXT NOT NULL
);
 
INSERT INTO `article`(`author_id`, `category_id`, `views`, `comments`, `title`, `content`) VALUES
(1, 1, 1, 1, '1', '1'),
(2, 2, 2, 2, '2', '2'),
(1, 1, 3, 3, '3', '3');
 
SELECT * FROM article;

2、案例

1.查询 category_id 为1且comments大于1的情况下，views最多的id

select id,author_id from article where category_id = 1 and comments > 1 order by views desc limit 1;

2.查看执行计划

结论：很显然type是ALL，即最坏的情况，全表扫描，Extra中还出现了Using filesort（文件排序）也是最坏的情况，因此需要优化。

3.尝试创建 复合索引 优化

create index idx_article_ccv on article(category_id,comments,views);

4.查看索引

show index from article;

5.查看执行计划

分析发现：使用了索引之后，type从ALL变成了range，表示使用了索引进行范围查询，key字段中也表明确实使用到了索引，但还是存在Using filesort（文件排序）。

原因：按照BTree索引的工作原理，先排序category_id，如果遇到相同的category_id则再排序comments，如果遇到相同的comments则再排序views，当comments字段在 复合索引 中间位置并且是一个范围查询（range），MySQL无法再对后面的 views部分进行检索。即range类型查询字段后面的索引无效。因此必须要舍弃范围的索引查询。

6.删除第一次的索引，并新建索引

-- 删除索引
drop index idx_article_ccv on article;
-- 创建新索引
create index idx_article_cv on article(category_id,views);

7.查看执行计划

发现不存在文件排序的问题，并且索引查询的类型为ref，属于可接受类型，优化完成。

2、关联查询优化

1、建表sql

CREATE TABLE IF NOT EXISTS `class` (
`id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE IF NOT EXISTS `book` (
`bookid` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`card` INT(10) UNSIGNED NOT NULL,
PRIMARY KEY (`bookid`)
);
 
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO class(card) VALUES(FLOOR(1 + (RAND() * 20)));
 
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));
INSERT INTO book(card) VALUES(FLOOR(1 + (RAND() * 20)));

2、案例

1.左外连接查询

select * from class left join book on class.card = book.card;

2.查看执行计划

分析发现：在没有索引的情况下查询，两表都进行了全表扫描，共计扫描了40条数据。

3.尝试在左表上建立索引，查询执行计划后

-- 在class表上建立索引
create index idx_card on class(card);

分析发现：在建立索引之后发现连接确实使用到了索引，但是扫描的行数没有变化，因此删除左表索引，在右表上建立。

4.删除索引，在右表建立索引，并查询执行计划

-- 删除索引
drop index idx_card on class;
-- 在右表建立索引
create index idx_card on book(card);

分析发现：不仅使用到了索引，而且右表没有进行全表扫描。明显查询性能提升。

总结：由于左右外连接的特性，左右外条件确定如何从对立的表进行搜索行，自身表数据一定全部都有，所以应当在对立的表上建立索引（左外在右表建索引，右外在左表建索引）。

3、索引失效（重点）

1、什么是索引失效？

就是指创建了索引，但是没有使用到，类似于单表优化案例中的range（范围查询），范围查询字段后面的索引无效

2、建表sql

-- 建表
CREATE TABLE staffs (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR (24)  NULL DEFAULT '' COMMENT '姓名',
  age INT NOT NULL DEFAULT 0 COMMENT '年龄',
  pos VARCHAR (20) NOT NULL DEFAULT '' COMMENT '职位',
  add_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '入职时间'
) CHARSET utf8 COMMENT '员工记录表';
-- 插入数据
INSERT INTO staffs(name,age,pos,add_time) VALUES('z3',22,'manager',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('July',23,'dev',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES('2000',23,'dev',NOW());
INSERT INTO staffs(name,age,pos,add_time) VALUES(null,23,'dev',NOW());
-- 创建复合索引
ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);

3、案例

1、查看sql执行计划

分析：这三种情况都使用了索引，匹配一个字段的时候索引长度为75，两个字段的时候索引长度79，三个的时候索引长度141，检索的行数都为1。这是正确的复合索引使用情况。

2、查看只查询age、pos两个字段的执行计划

分析：发现都是进行全表扫描，没有用到索引，由此可见之前建立的复合索引失效了。

3、查看只查询name、pos两个字段的执行计划

分析：第一条sql执行计划上可以看出，确实是使用到了索引，但是索引的长度与第二条执行计划中（仅使用name字段进行查询）的索引长度一样，也就是说第一条sql执行计划中的索引也是失效的。

结论：由此可知，索引失效或者部分失效的原因可能是违背了 最佳左前缀法则。

4、最佳左前缀法则

如果索引有多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。查询条件的字段应该与复合索引的字段保持一致，顺序不一致不要紧，因为mysql会内部对查询条件进行顺序转换，转换为和复合索引一致的情况。

5、其他失效案例及注意

1.不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

2.索引中范围条件右边的列索引会失效

分析：第一条sql中，查询使用到了索引，类型为ref，索引长度为79，第二条sql中虽然也用到了索引，但是类型为range（范围查询）再看索引的长度，与第一条sql的索引长度一样，比三个索引都使用到的第三条sql中索引长度小很多，因此，可以看出第二条sql中索引失效。

3.尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *

4.mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描

5.is not null 也无法使用索引,但是is null是可以使用索引的

6.like以通配符开头(’%abc…’)mysql索引失效会变成全表扫描的操作

分析：发现like中%在右边的情况下索引不会失效

如果非要使用在like左边使用%号并且解决索引失效问题(使用覆盖索引的方式)

-- 新建一个表
CREATE TABLE `tbl_user` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`NAME` VARCHAR(20) DEFAULT NULL,
`age` INT(11) DEFAULT NULL,
`email` VARCHAR(20) DEFAULT NULL,
PRIMARY KEY (`id`)
)ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
-- 数据
INSERT INTO tbl_user(NAME,age,email) VALUES('1aa1',21,'[email protected]');
INSERT INTO tbl_user(NAME,age,email) VALUES('2aa2',222,'[email protected]');
INSERT INTO tbl_user(NAME,age,email) VALUES('3aa3',265,'[email protected]');
INSERT INTO tbl_user(NAME,age,email) VALUES('4aa4',21,'[email protected]');
INSERT INTO tbl_user(NAME,age,email) VALUES('aa',121,'[email protected]');
-- 在name字段上建立索引，形成覆盖索引
create index idx_user_name on tbl_user(name);

分析：

• 因为在name上建立了索引，而且查询字段也不是 select *，就不会索引失效（第一条执行计划）。

• 因为id自带索引，name也建立了索引，也不会索引失效（第二条执行计划）。

• 因为查询的字段不符合覆盖索引的规律，因此索引会失效（第三、四条执行计划）。

7.字符串类型字段查询时不加单引号索引会失效

分析：字符串类型不加单引号，由于字段类型是字符串类型，而传入值是没有加单引号的，mysql会认为传递的是一个整数类型，底层会自动类型转换，导致索引失效。

8.用or连接时会导致索引失效

4、order by优化

order by子句，尽量使用Index方式排序，避免使用FileSort（文件排序）方式排序。

1、建表sql

-- 建表
CREATE TABLE tblA(
  id int primary key not null auto_increment,
  age INT,
  birth TIMESTAMP NOT NULL,
  name varchar(200)
);
-- 数据
INSERT INTO tblA(age,birth,name) VALUES(22,NOW(),'abc');
INSERT INTO tblA(age,birth,name) VALUES(23,NOW(),'bcd');
INSERT INTO tblA(age,birth,name) VALUES(24,NOW(),'def');
-- 建组合索引
CREATE INDEX idx_A_ageBirth ON tblA(age,birth,name);

2、案例

1.尽可能在索引列上完成排序操作，遵循索引键的最佳左前缀法则

分析：建立索引的顺序是age，birth，name，当order by遵循了索引的最佳左前缀法则的时候是可以按照索引进行排序的（第一二条执行计划都遵循了最佳左前缀法则，因此都用到了索引排序）；如果没有遵循，就不会按照索引进行排序，就会出现using filesort（文件排序，第三条执行计划没有按照索引进行排序）。

2.当遇到多排序的时候，不仅要遵循最佳左前缀法则，还需要排序的顺序一致，不能一个升序一个降序,，否则会出现文件排序

3.当where和order by同时出现时，where中字段遵循了索引最佳左前缀法则，且定义为常量，order by中不遵循最佳左前缀法则也能使用索引排序，反之，则不能使用索引排序，会出现文件排序（using filesort）

原因：order by子句可以使用被定义为常量的where子句条件字段与自身字段组合成完整的复合索引。

4.where子句中使用了范围查询，只要order by 子句中的字段能够与范围查询之前的字段组成复合索引，并且遵循索引的最佳左前缀法则，则不会出现文件排序

3、文件排序（Using filesort）算法

order by没有使用到索引的时候就会出现文件排序，文件排序有两种算法（双路、单路排序）。

1、双路排序

Mysql4.1之前是使用双路排序，字面的意思就是两次扫描磁盘，最终得到数据，读取行指针和ORDER BY列，对他们进行排序，然后扫描已经排好序的列表，按照列表中的值重新从列表中读取对数据输出。也就是从磁盘读取排序字段，在buffer进行排序，再从磁盘读取其他字段。文件的磁盘I\O非常耗时的。

2、单路排序

从磁盘读取查询需要的所有列，按照order by列在buffer中对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO，但是它会使用更多的空间，因为它把每一行都保存在内存中了。

3、单路排序失效的情况

在sort_buffer中，单路排序要比双路排序占很多空间，因为单路排序把所有的字段都取出，所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能读取sort_buffer容量大小的数据，进行排序(创建tmp文件，多路合并)，排完再取sort_buffer容量大小，再次排序，如此循环，从而多次操作I/O。

比如：内存就是2M，一次查1000条数据刚好，也就是最大1000条数据，但是一次要查5000条，那么不够了，照这样需要查5次刚好，如果把2M改为10M，那么就刚好了。

4、总结

1. 排序的时候 select * 是一个大忌，只查询需要的字段即可。

2. 尝试提高 sort_buffer_size 的值，不管是用哪种算法，提高这个参数都会提高效率，当然需要根据系统的能力去提高，因为这个参数是针对进程的。

3. 尝试提高 max_length_for_sort_data 的值，会增加使用单路算法的概率，但是如果太高，数据总容量超出 sort_buffer_size 的概率就会增大，从而频繁操作IO，及处理器使用率降低。

5、group by优化

• group by实质是先排序后进行分组，遵照索引键的最佳左前缀法则。
• 当无法使用索引列，增大 max_length_for_sort_data 参数的设置和增大 sort_buffer_size 参数的设置。
• 在group by子句中有having关键字，where高于having，能写在where限定的条件就不要去having限定。

五、慢查询日志

1、概述

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阀值的语句，具体指运行时间超过long_query_time 值的SQL，则会被记录到慢查询日志中。long_query_time 的默认值为10s，意思是运行10秒以上的语句会被慢查询日志记录下来，等于10s的不会被记录下来。

默认情况下，MySQL数据库没有开启慢查询日志，需要我们手动来设置这个参数。当然，如果不是调优需要的话，一般不建议启动该参数 ，因为开启慢查询日志会或多或少带来一定的性能影响。慢查询日志支持将日志记录写入文件。

2、操作

1、查看是否开启慢查询日志

2、开启慢查询日志

3、查看 long_query_time 的值

注：关于这个参数的值，可以通过命令 set global long_query_time = 3; 来修改，也可以在mysql配置文件my.cnf中修改，修改完后需要使用 show global variables like '%long_query_time%'; 命令查看或者是重新连接一次使用之前的命令查看。

4、实验一条慢sql

因为当前环境无法模拟超过3s的慢sql，所以用 select sleep(4) 来模拟慢sql，等待4s

查看慢日志文件

5、查看当前系统记录了多少条慢sql信息

3、show profile

show profile是mysql提供可以用来分析当前会话中语句执行的资源消耗情况。可以用于SQL的调优的测量。默认情况下，参数处于关闭状态，并保存最近15次的执行结果。

1、查看当前mysql是否支持show variables like 'profiling';

默认是关闭，使用前需要开启。

2、开启set profiling = 1

3、运行sql

select * from emp group by id%10 limit 150000;
select * from emp group by id%20  order by 5;

4、查看结果show profiles;

通过上述命令。可以查看查看sql的详细执行时间及对应的query_id和查询的sql语句。

5、可以通过query_id查看详细执行过程show profile cpu,block io for query query_id

sql详细执行过程可以查看的参数有很多，上述只查询了cpu，block io的内容，可选参数列表如下：

• ALL：显示所有的开销信息
• BLOCK IO：显示块IO开销信息
• CONTEXT SWITCHES：显示上下文切换开销
• CPU：显示CPU开销
• IPC：显示发送和接收相关开销
• MEMORY：显示内存相关开销
• PAGE FAULTS：显示页面错误相关开销
• SOURCE：显示和Source_function，Source_file，Source_line相关的开销
• SWAPS：显示交换次数相关开销

6、注意事项

show profiles会展示出很多的详细信息，但并不是所有的都值得关注，当出现以下情况的时，说明sql出现了比较严重的问题

• converting HEAP to MyISAM：查询结果太大，内存都不够用了还往磁盘上放。
• Creating tmp table：创建临时表，拷贝数据到临时表，用完之后再删除临时表，开销十分大。
• Copying to tmp table on disk：把内存中临时表复制到磁盘

4、全局查询日志

全局查询日志会将你所执行的所有的sql信息都记录下来，该功能仅适合在测试环境中使用，切记不要在生产中开启该功能。

开启全局查询日志：set global general_log=1;

设置以表的形式输出日志：set global log_output='TABLE';

开启了之后mysql会将你执行的所有sql的情况记录在mysql库的general_log表中。

查看全局日志信息：select * from mysql.general_log;