MySQL高级学习笔记（四）：索引优化分析
文章目录
- 性能下降 SQL慢 执行时间长 等待时间长
- 查询语句写的烂
- 查询数据过多
- 关联了太多的表，太多join
- 没有利用到索引
- 单值
- 复合
- 服务器调优及各个参数设置（缓冲、线程数等）(不重要DBA的工作)
- 常见通用的Join查询
- SQL执行顺序
- 手写
- 机读
- 总结
- Join图
- 共有与独有(理解)
- 建表SQL
- 7种JOIN
- 增加掌门字段
- join 的理解例题
- 索引简介
- 是什么
- 优势
- 劣势
- mysql索引结构
- BTree索引( Myisam普通索引)
- 原理图
- 关于时间复杂度
- B+Tree索引( innodb的普通索引)
- 原理图
- B树和B+树的区别
- 聚簇索引与非聚簇索引
- full-text全文索引
- Hash索引
- R-Tree索引
- mysql索引分类
- 主键索引
- 语法
- 单值索引
- 语法
- 唯一索引
- 语法
- 复合索引
- 不理解
- 即一个索引包含多个列
- 语法
- 基本语法
- 创建
- 删除
- 查看
- 使用ALTER命令
- 哪些情况需要创建索引
- 哪些情况不要创建索引
- 性能分析
- MySQL Query Optimizer
- MySQL常见瓶颈
- CPU
- IO：
- 锁
- 服务器硬件的性能瓶颈：top,free, iostat和vmstat来查看系统的性能状态
- Explain
- 是什么(查看执行计划)
- 能干嘛
- 怎么玩
- 各字段解释
- id
- select_type
- table
- type
- 访问类型排列：
- 显示查询使用了何种类型， 从最好到最差依次是： system>const>eq_ref>ref>range>index>ALL
- possible_keys
- key
- key_len
- 表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。
- key_len字段能够帮你检查是否充分的利用上了索引
- ref
- rows
- Extra （重点前三个）
- 热身case
- 查询优化
- 使用索引
- 小案例
- 单表
- 两表
- 三表
- 建表SQL
- 案例(索引失效)
- 热身case
- 一般性建议
- 单表查询优化
- 建表SQL
- 案例
- 关联查询优化
- 建表SQL
- 案例
- 建议
- 子查询优化
- 实验
- 结论
- order by关键字优化
- ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序
- 建表SQL
- Case
- MySQL支持二种方式的排序，FileSort和Index，Index效率高. 它指MySQL扫描索引本身完成排序。FileSort方式效率较低。
- ORDER BY满足两情况，会使用Index方式排序:
- 尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀
- 如果不在索引列上，filesort有两种算法： mysql就要启动双路排序和单路排序
- 分页查询的优化---limit
- GROUP BY关键字优化
- 去重优化
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
性能下降 SQL慢 执行时间长 等待时间长
查询语句写的烂
查询数据过多
能不能拆，条件过滤尽量少
关联了太多的表，太多join
join 原理。用 A 表的每一条数据 扫描 B表的所有数据。所以尽量先过滤。
没有利用到索引
单值
复合
条件多时，可以建共同索引(混合索引)。混合索引一般会偶先使用。
有些情况下，就算有索引具体执行时也不会被使用。
服务器调优及各个参数设置（缓冲、线程数等）(不重要DBA的工作)
常见通用的Join查询
SQL执行顺序
手写
机读
随着 Mysql 版本的更新换代，其优化器也在不断的升级，优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。
下面是经常出现的查询顺序：
先从from开头
总结
如下：
from a,b 4x5=20 笛卡尔积
Join图
如下：
共有与独有(理解)
什么叫共有，什么叫独有？
共有 ：满足 a.deptid = b.id 的叫共有
A独有 : A 表中所有不满足 a.deptid = b.id 连接关系的数据
同时参考 join 图
建表SQL
CREATE TABLE `t_dept` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`deptName` VARCHAR(30) DEFAULT NULL,
`address` VARCHAR(40) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
CREATE TABLE `t_emp` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`name` VARCHAR(20) DEFAULT NULL,
`age` INT(3) DEFAULT NULL,
`deptId` INT(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `fk_dept_id` (`deptId`)
#CONSTRAINT `fk_dept_id` FOREIGN KEY (`deptId`) REFERENCES `t_dept` (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
INSERT INTO t_dept(deptName,address) VALUES('华山','华山');
INSERT INTO t_dept(deptName,address) VALUES('丐帮','洛阳');
INSERT INTO t_dept(deptName,address) VALUES('峨眉','峨眉山');
INSERT INTO t_dept(deptName,address) VALUES('武当','武当山');
INSERT INTO t_dept(deptName,address) VALUES('明教','光明顶');
INSERT INTO t_dept(deptName,address) VALUES('少林','少林寺');
INSERT INTO t_emp(NAME,age,deptId) VALUES('风清扬',90,1);
INSERT INTO t_emp(NAME,age,deptId) VALUES('岳不群',50,1);
INSERT INTO t_emp(NAME,age,deptId) VALUES('令狐冲',24,1);
INSERT INTO t_emp(NAME,age,deptId) VALUES('洪七公',70,2);
INSERT INTO t_emp(NAME,age,deptId) VALUES('乔峰',35,2);
INSERT INTO t_emp(NAME,age,deptId) VALUES('灭绝师太',70,3);
INSERT INTO t_emp(NAME,age,deptId) VALUES('周芷若',20,3);
INSERT INTO t_emp(NAME,age,deptId) VALUES('张三丰',100,4);
INSERT INTO t_emp(NAME,age,deptId) VALUES('张无忌',25,5);
INSERT INTO t_emp(NAME,age,deptId) VALUES('韦小宝',18,null);
7种JOIN
1 A、B两 表共有
select * from t_emp a inner join t_dept b on a.deptId = b.id;
2 A 、 B 两表共有+A的独有
select * from t_emp a left join t_dept b on a.deptId = b.id;
3 A 、 B 两表共有+B的独有
select * from t_emp a right join t_dept b on a.deptId = b.id;
4 A 的独有
select * from t_emp a left join t_dept b on a.deptId = b.id where b.id is null;
5 B的独有
select * from t_emp a right join t_dept b on a.deptId = b.id where a.deptId is null;
6 AB全有
#MySQL Full Join的实现 因为MySQL不支持FULL JOIN,下面是替代方 法
#left join + union(可去除重复数据，合并加去重)+ right join
SELECT * FROM t_emp A LEFT JOIN t_dept B ON A.deptId = B.id
UNION
SELECT * FROM t_emp A RIGHT JOIN t_dept B ON A.deptId = B.id
这里因为要联合的缘故，不能考虑到小表驱动大表的情况。只能用right join。要保证查询出来的数字要一致。
7 A的独有+B的独有
SELECT * FROM t_emp A LEFT JOIN t_dept B ON A.deptId = B.id WHERE B.`id` IS NULL
UNION
SELECT * FROM t_emp A RIGHT JOIN t_dept B ON A.deptId = B.id WHERE A.`deptId` IS NULL;
增加掌门字段
ALTER TABLE `t_dept`
add CEO INT(11) ;
update t_dept set CEO=2 where id=1;
update t_dept set CEO=4 where id=2;
update t_dept set CEO=6 where id=3;
update t_dept set CEO=8 where id=4;
update t_dept set CEO=9 where id=5;
求各个门派对应的掌门人:
select * from t_dept as b left join t_emp as a on b.CEO=a.id;
求所有当上掌门人的平均年龄:
select avg(a.age) from t_emp a inner join t_dept b on a.id=b.CEO ;
join 的理解例题
两者区别 ：
思想上的区别：
子查询理解 ：①先知道需要查询并将数据拿出来(若from 后的表也是一个子查询结果)。②在去寻找满足判断条件的数据(where,on,having 后的参数等)。而这些查询条件通常是通过子查询获得的。
子查询是一种根据结果找条件的倒推的顺序。比较好理解与判断
例题中：“人物”在t_emp 表中，所以第一个from 是t_emp 表。(也可以直接将子查询方法 from 后面(因为本题中的子查询中也有select 的数据),所以任然需要上述的推导过程)
join理解 ：执行完第一步后的结果为一张新表。在将新表与 t_emp 进行下一步的 left join 关联。
先推出如何获得条件，再像算数题一样一步一步往下 join。可以交换顺序，但只能是因为条件间不相互关联时才能交换顺序。
join 比 子查询难一点
join 能用到索引，但是子查询出来的表会使索引失效。
***求所有人物对应的掌门:
t_dept 表
id deptName address CEO
1 华山派 华山 2
…
t_emp 表
id name age deptId
1 风清扬 90 1
…
1.使用子查询 (不推荐，影响后续用索引)
步骤：a.创建子查询 查询出每个门派对应的ceo
b. 根据t_emp 对应的 deptId 关联子查询表查询出所有人物对应的 ceo
SELECT a.name,f.deptName,f.name FROM t_emp a
LEFT JOIN (SELECT d.id,e.name ,d.deptName FROM t_dept d
LEFT JOIN t_emp e
ON d.CEO=e.id) f
ON a.deptId = f.id
2.使用join (推荐)
步骤:a. 关联出每个人物对应的门派
b.通过门派的 ceo 关联对应的掌门
SELECT e.name, d.deptName,f.name ceo FROM t_dept d
RIGHT JOIN t_emp e
ON d.id = e.deptId ##第一步 —>得到关联了部门的一张新的联合表
LEFT JOIN t_emp f
ON d.CEO=f.id ##第二步 —>通过新的联合表中的数据与另一张表关联
SELECT d.deptName, e.name CEO,d.id,f.name
FROM t_dept d
LEFT JOIN t_emp e //上述两个 join 交换了顺序并不影响执行。前提是两个 join 间不是依赖关系。且都跟
ON d.CEO=e.id
LEFT JOIN t_emp f
ON f.deptId = d.id
索引简介
是什么
MySQL官方对索引的定义为：索引（Index）是帮助MySQL高效获取数据的数据结构。 可以得到索引的本质： 索引是数据结构。
索引的目的在于提高查询效率，可以类比字典，
如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。
如果没有索引，那么你可能需要a----z，如果我想找到Java开头的单词呢？或者Oracle开头的单词呢？
是不是觉得如果没有索引，这个事情根本无法完成？
你可以简单理解为“排好序的快速查找数据结构”。
详解(重要)
在数据之外， 数据库系统还维护着满足特定查找算法的数据结构 ，这些数据结构以某种方式引用（指向）数据，
这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。下图就是一种可能的索引方式示例：
 
右边的树就相当于索引
左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址
为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在一定的复杂度内获取到相应数据，从而快速的检索出符合条件的记录。
二叉树弊端之一：二叉树很可能会发生两边不平衡的情况。
B-TREE: (B:balance) 会自动根据两边的情况自动调节，使两端无限趋近于平衡状态。可以使性能最稳定。(myisam使用的方式)
B-TREE弊端：(插入/修改操 作多时，B-TREE会不断调整平衡，消耗性能)从侧面说明了索引不是越多越好。
B+TREE:Innodb 所使用的索引
解决where和orderby
结论
数据本身之外，数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这种数据结构就是索引。
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上
我们平常所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉的)结构组织的索引 。其中聚集索引，次要索引，覆盖索引， 复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈稀索引(hash index)等。
优势
类似大学图书馆建书目索引，提高数据检索的效率，降低数据库的IO成本(磁盘io，检索需要不断地磁盘io)
通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗
劣势
实际上索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录，所以索引列也是要占用空间的
虽然索引大大提高了查询速度，同时却会降低更新表的速度
删改了表之后需要更新索引
，如对表进行INSERT、UPDATE和DELETE。 因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段， 都会调整因为更新所带来的键值变化后的索引信息
索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句
mysql索引结构
BTree索引( Myisam普通索引)
原理图
【初始化介绍】
一颗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由磁盘加载到内存，此时发生一次IO，在内存中用二分查找确定29在17和35之间，锁定磁盘块1的P2指针，内存时间因为非常短（相比磁盘的IO）可以忽略不计，通过磁盘块1的P2指针的磁盘地址把磁盘块3由磁盘加载到内存，发生第二次IO，29在26和30之间，锁定磁盘块3的P2指针，通过指针加载磁盘块8到内存，发生第三次IO，同时内存中做二分查找找到29，结束查询，总计三次IO。
真实的情况是，3层的b+树可以表示上百万的数据，如果上百万的数据查找只需要三次IO，性能提高将是巨大的，如果没有索引，每个数据项都要发生一次IO，那么总共需要百万次的IO，显然成本非常非常高。
关于时间复杂度
同一问题可用不同算法解决，而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法。
 
 
1 N logN 分别表示数据与查询次数之间的关系。
常数 1c 表示查询最快的方式。查询次数不随数据的增加而增加
变量 N 表示查询次数随数据数量的增加而增加
对数 logN 表示查询次数与数据数量成对数关系。 介于常数与 N 之间。
nlogN 表示使用的复合方法。
B+Tree索引( innodb的普通索引)
原理图
B+TREE 第二级的 数据并不能直接取出来，只作索引使用。在内存有限的情况下，查询效率高于 B-TREE
B-TREE 第二级可以直接取出来，树形结构比较重，在内存无限大的时候有优势。
B树和B+树的区别
B+Tree与B-Tree 的区别：结论在内存有限的情况下，B+TREE 永远比 B-TREE好。无限内存则后者方便
1）B-树的关键字和记录是放在一起的，叶子节点可以看作外部节点，不包含任何信息；B+树叶子节点中只有关键字和指向下一个节点的索引，记录只放在叶子节点中。(一次查询可能进行两次i/o操作)
2）在B-树中，越靠近根节点的记录查找时间越快，只要找到关键字即可确定记录的存在；而B+树中每个记录的查找时间基本是一样的，都需要从根节点走到叶子节点，而且在叶子节点中还要再比较关键字。从这个角度看B-树的性能好像要比B+树好，而在实际应用中却是B+树的性能要好些。因为B+树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比B-树多，树高比B-树小，这样带来的好处是减少磁盘访问次数。尽管B+树找到一个记录所需的比较次数要比B-树多，但是一次磁盘访问的时间相当于成百上千次内存比较的时间，因此实际中B+树的性能可能还会好些，而且B+树的叶子节点使用指针连接在一起，方便顺序遍历（例如查看一个目录下的所有文件，一个表中的所有记录等），这也是很多数据库和文件系统使用B+树的缘故。
思考：为什么说B+树比B-树更适合实际应用中操作系统的文件索引和数据库索引？
- B+树的磁盘读写代价更低
B+树的内部结点并没有指向关键字具体信息的指针。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。 - B+树的查询效率更加稳定
由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。
聚簇索引与非聚簇索引
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。
术语‘聚簇’表示数据行和相邻的键值进错的存储在一起。
如下图，左侧的索引就是聚簇索引，因为数据行在磁盘的排列和索引排序保持一致。

聚簇索引的好处：
• 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量的io操作。
聚簇索引的限制：
• 对于mysql数据库目前只有innodb数据引擎支持聚簇索引，而Myisam并不支持聚簇索引。
• 由于数据物理存储排序方式只能有一种 ，所以每个Mysql的表只能有一个聚簇索引。一般情况下就是该表的主键 。
• 为了充分利用聚簇索引的聚簇的特性，所以innodb表的主键列尽量选用有序的顺序id，而不建议用无序的id，比如uuid这种。（参考聚簇索引的好处。）
这里说明了主键索引为何采用自增的方式：1、业务需求，有序。2、能使用到聚簇索引
full-text全文索引
全文索引（也称全文检索）是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性，然后按照一定的算法规则智能地筛选出我们想要的搜索结果。
CREATE TABLE article (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
title varchar(200) DEFAULT NULL,
content text,
PRIMARY KEY (id),
FULLTEXT KEY title (title,content)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
不同于like方式的的查询：
SELECT * FROM article WHERE content LIKE ‘%查询字符串%’;
全文索引用match+against方式查询：
SELECT * FROM article WHERE MATCH(title,content) AGAINST (‘查询字符串’);
明显的提高查询效率。
限制：
mysql5.6.4以前只有Myisam支持，5.6.4版本以后innodb才支持，但是官方版本不支持中文分词，需要第三方分词插件。
5.7以后官方支持中文分词。
随着大数据时代的到来，关系型数据库应对全文索引的需求已力不从心，逐渐被 solr,elasticSearch等专门的搜索引擎所替代。
Hash索引
Hash索引只有Memory, NDB两种引擎支持，Memory引擎默认支持Hash索引，如果多个hash值相同，出现哈希碰撞，那么索引以链表方式存储。
NoSql采用此中索引结构。
R-Tree索引
R-Tree在mysql很少使用，仅支持geometry数据类型，支持该类型的存储引擎只有myisam、bdb、innodb、ndb、archive几种。
相对于b-tree，r-tree的优势在于范围查找。
mysql索引分类
主键索引
设定为主键后数据库会自动建立索引，innodb为聚簇索引
语法
随表一起建索引：
CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT ,customer_no VARCHAR(200),customer_name VARCHAR(200),
PRIMARY KEY(id)
);
unsigned (无符号的)
使用 AUTO_INCREMENT 关键字的列必须有索引(只要有索引就行)。
CREATE TABLE customer2 (id INT(10) UNSIGNED ,customer_no VARCHAR(200),customer_name VARCHAR(200),
PRIMARY KEY(id)
);
单独建主键索引：
ALTER TABLE customer
add PRIMARY KEY customer(customer_no);
删除 建主键索引：
ALTER TABLE customer
drop PRIMARY KEY ;
修改 建主键索引：
必须先删除掉(drop)原索引，再新建(add)索引
单值索引
即一个索引只包含单个列，一个表可以有多个单列索引
语法
索引建立成哪种索引类型？
根据数据引擎类型自动选择的索引类型
除开 innodb 引擎主键默认为聚簇索引 外。 innodb 的索引都采用的 B+TREE
myisam 则都采用的 B-TREE索引
唯一索引
索引列的值必须唯一，但允许有空值
语法
随表一起建索引：
CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT ,customer_no VARCHAR(200),customer_name VARCHAR(200),
PRIMARY KEY(id),
KEY (customer_name),
UNIQUE (customer_no)
);
建立 唯一索引时必须保证所有的值是唯一的（除了null），若有重复数据，会报错。
单独建唯一索引：
CREATE UNIQUE INDEX id x_customer_no ON customer(customer_no);
删除 索引：
DROP INDEX idx_customer_no on customer ;
复合索引
不理解
复合索引与单值索引有什么区别？
复合索引：create index idx_no_name on emp(no,name); // no 与 name 有同一个索引 idx_no_name
单值索引：create index idx_no on emp(no);
create index idx_name on emp(name);
疑惑：同一数据引擎，都是采用一样的索引类型(B-TREE或B+TREE),复合索引与单值索引的区别是什么？该怎么使用？
即一个索引包含多个列
在数据库操作期间，复合索引比单值索引所需要的开销更小(对于相同的多个列建索引)
当表的行数远大于索引列的数目时可以使用复合索引
语法
随表一起建索引：
CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT ,customer_no VARCHAR(200),customer_name VARCHAR(200),
PRIMARY KEY(id),
KEY (customer_name),
UNIQUE (customer_name),
KEY (customer_no,customer_name)
);
单独建索引：
CREATE INDEX idx_no_name ON customer(customer_no,customer_name);
删除 索引：
DROP INDEX idx_no_name on customer ;
基本语法
创建
//UNIQUE唯一索引关键字
ALTER mytable ADD [UNIQUE ] INDEX [indexName] ON (columnname(length))
删除
DROP INDEX [indexName] ON mytable;
查看
SHOW INDEX FROM table_name\G
\Gs是竖着看，注意后面没有分号。
non_unique: 是否是唯一索引 1：是 0：不是
seq_in_index:列 在索引中的 序列。针对符合索引(一个索引对应多个列)。针对同一个复合索引 按照创建复合索引时的顺序进行排序
collation:
cardinality:
sub_part:
packed:
Null:是否允许 null 值
comment:
index_comment:
使用ALTER命令
有四种方式来添加数据表的索引：
ALTER TABLE tbl_name ADD PRIMARY KEY (column_list): 该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。
ALTER TABLE tbl_name ADD UNIQUE index_name (column_list): 这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。
ALTER TABLE tbl_name ADD INDEX index_name (column_list): 添加普通索引，索引值可出现多次。
ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list):该语句指定了索引为 FULLTEXT ，用于全文索引。
哪些情况需要创建索引
-
主键自动建立唯一索引
-
频繁作为查询条件的字段应该创建索引(where 后面的语句)
-
查询中与其它表关联的字段，外键关系建立索引
A 表关联 B 表：A join B 。 on 后面的连接条件 既 A 表查询 B 表的条件。所以 B 表被关联的字段建立索引能大大提高查询效率
因为在 join 中，join 左边的表会用每一个字段去遍历 B 表的所有的关联数据，相当于一个查询操作 -
单键/组合索引的选择问题，who？(在高并发下倾向创建组合索引)
-
查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
group by 和 order by 后面的字段有索引大大提高效率 -
查询中统计或者分组字段
哪些情况不要创建索引
- 表记录太少
- 经常增删改的表
Why:提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。 因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件 - Where条件里用不到的字段不创建索引
索引建多了影响 增删改 的效率 - 数据重复且分布平均的表字段，因此应该只为最经常查询和最经常排序的数据列建立索引。 注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
比如，一个班的同学的族，都是中汉族，汉族这个字段就不需要建立索引 - 频繁更新的字段不适合创建索引，因为每次更新不单单是更新了记录，还更新了索引。
性能分析
MySQL Query Optimizer
Mysq中有专门负责优化 SELECT语句的优化器模块,主要功能:通过计算分析系统中收集到的统计信息,为客户端请求的 Query提供他认为最优的执行计划(他认为最优的数据检索方式,但不见得是DBA认为是最优的这部分最耗费时间)
当客户端向MySαL请求一条 Query,命令解析器模块完成请求分类,区别出是 SELECT并转发给 MySQL Query Optimizer时, MySQL Query Optimizer首先会对整条 Query进行优化,处理掉一些常量表达式的预算直接换算成常量值。并对 Query中的查询条件进行简化和转换,如去掉一些无用或显而易见的条件、结构调整等。然后分析 Query中的Hnt信息(如果有),看显示Hint信息是否可以完全确定该 Query的执行计划。如果没有Hnt或Hint信息还不足以完全确定执行计划,则会读取所涉及对象的统计信息,根据 Query进行写相应的计算分析,然后再得出最后的执行计划
MySQL常见瓶颈
CPU
SQL中对大量数据进行比较、关联、排序、分组
最大的压力在于 比较
IO：
实例内存满足不了缓存数据或排序等需要，导致产生大量 物理 IO。
查询执行效率低，扫描过多数据行。
锁
不适宜的锁的设置，导致线程阻塞，性能下降。
死锁，线程之间交叉调用资源，导致死锁，程序卡住。
服务器硬件的性能瓶颈：top,free, iostat和vmstat来查看系统的性能状态
Explain
是什么(查看执行计划)
使用EXPLAIN关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是 如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈
官方介绍：
http://dev.mysql.com/doc/refman/5.5/en/explain-output.html
能干嘛
表的读取顺序（id）
哪些索引可以使用（select_type）
数据读取操作的操作类型（possible_key）
哪些索引被实际使用(key)
表之间的引用
每张表有多少行被优化器查询（rows）
怎么玩
Explain + SQL语句
执行计划包含的信息
建表脚本
CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000)));
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000)));
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000)));
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));
各字段解释
id
select查询的序列号,包含一组数字，表示查询中执行select子句或操作表的顺序
表的读取顺序
三种情况
- id相同，执行顺序由上至下
id相同， 执行顺序由上至下
1->3->2
此例中 先执行where 后的第一条语句 t1.id = t2.id 通过 t1.id 关联 t2.id 。 而 t2.id 的结果建立在 t2.id=t3.id 的基础之上。
- id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
id 不同，如果是子查询， id 的序号会递增， id 值越大优先级越高，越先被执行
3->2->1
- id相同不同，同时存在
id如果相同，可以认为是一组，从上往下顺序执行；
在所有组中，id值越大，优先级越高，越先执行
3–>derived2–>2
衍生表 = derived2 --> derived + 2 （2 表示由 id =2 的查询衍生出来的表。type 肯定是 all ，因为衍生的表没有建立索引）
select_type
有哪些
查询的类型，主要是用于区别 普通查询、联合查询、子查询等的复杂查询：
-
SIMPLE
简单的 select 查询,查询中不包含子查询或者UNION
-
PRIMARY
查询中若包含任何复杂的子部分，最外层查询则被标记为Primary，也就是最后查询的那个
-
DERIVED
在FROM列表中包含的子查询被标记为DERIVED(衍生) MySQL会递归执行这些子查询, 把结果放在临时表里。
DERIVED 既查询通过子查询查出来的 临时表 -
SUBQUERY
在SELECT或WHERE列表中包含了子查询
-
DEPENDENT SUBQUERY 在SELECT或WHERE列表中包含了子查询,子查询基于外层
dependent subquery 与 subquery 的区别
依赖子查询 ： 子查询结果为 多值
子查询：查询结果为 单值 -
UNCACHEABLE SUBQUREY
无法被缓存的子查询
图1 中的 @@ 表示查的环境参数 。没办法缓存 -
UNION
若第二个SELECT出现在UNION之后，则被标记为UNION； 若UNION包含在FROM子句的子查询中,外层SELECT将被标记为：DERIVED
UNION RESULT 两个语句执行完后的结果 -
UNION RESULT
从UNION表获取结果的SELECT
table
显示这一行的数据是关于哪张表的
type
百万级别以上，不要出现all，建议到renge后者ref
访问类型排列：
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。
显示查询使用了何种类型， 从最好到最差依次是： system>const>eq_ref>ref>range>index>ALL
system
表只有一行记录（等于系统表），这是const类型的特列，平时不会出现，这个也可以忽略不计
const
表示通过索引一次就找到了,const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快 如将主键置于where列表中，MySQL就能将该查询转换为一个常量
eq_ref
唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
ref
非唯一性索引扫描，返回匹配某个单独值的所有行. 本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而， 它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体
range
只检索给定范围的行,使用一个索引来选择行。key 列显示使用了哪个索引 一般就是在你的where语句中出现了between、<、>、in等的查询 这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束语另一点，不用扫描全部索引。
index
Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。 （也就是说虽然all和Index都是读全表，但index是从索引中读取的，而all是从硬盘中读的）
all
Full Table Scan，将遍历全表以找到匹配的行
index_merge
在查询过程中需要多个索引组合使用，通常出现在有 or 的关键字的sql中
ref_or_null
对于某个字段既需要关联条件，也需要null值得情况下。查询优化器会选择用ref_or_null连接查询。
index_subquery
利用索引来关联子查询，不再全表扫描。
unique_subquery
该联接类型类似于index_subquery。 子查询中的唯一索引
备注：一般来说，得保证查询至少达到range级别，最好能达到ref。
possible_keys
显示可能应用在这张表中的索引，一个或多个。 查询涉及到的字段上若存在索引，则该索引将被列出 ， 但不一定被查询实际使用
key
实际使用的索引。如果为NULL，则没有使用索引
查询中若使用了覆盖索引，则该索引和查询的select字段重叠
这句话生涩难懂啊，什么鸡巴鬼
对比下图两个 sql 语句。和 key 的值：当查询具体某一字段时，且那个字段有索引时，key 值会显示为索引。
左边的posible_key为null，但是key中有值，所以最终还是要看key里面的
key_len
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。
在不损失精度的情况下，长度越短越好
key_len显示的值为索引字段的最大可能长度， 并非实际使用长度 ，即key_len是根据定义计算而得，不是通过表内检索出
表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。
EXPLAIN SELECT * FROM emp WHERE emp.deptno=109 AND emp.ename=‘AvDEjl’
如何计算
总结一下：char(30) utf8 --> key_len = 30*3 +1 表示 utf8 格式需要 *3 (跟数据类型有关)
允许为 NULL +1 ，不允许 +0
动态类型 +2 (动态类型包括 : varchar , detail text() 截取字符窜)

第一组：key_len=deptno(int)+null + ename(varchar(20)3+动态 =4+1+203+2= 67
第二组：key_len=deptno(int)+null=4+1=5
key_len字段能够帮你检查是否充分的利用上了索引
GROUP BY emp.deptno
HAVING c >2
ORDER BY c DESC
同样的使用了索引但是索引的涉及的字段却不同。

下图可知，充分的利用了索引的查询效率会更高。
 
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数。哪些列或常量被用于查找索引列上的值
rows
rows列显示MySQL认为它执行查询时必须检查的行数。
根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数。
越少越好
Extra （重点前三个）
包含不适合在其他列中显示但 十分重要的额外信息
- Using filesort
说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取。 MySQL中无法利用索引完成的排序操作称为“文件排序”
看上图：
索引是 col1 col2 col3 ，第一个sql where col1 oder by col3 ，中间的col2没有了
也就是排序的时候用到了索引，但是查找的时候没有用，而是用的系统自己的filesort进行查找的，所以索引白白建立了。
经过优化： where col1 oderby col2 col3 ，按照建立索引的顺序，进行查找，发现Extra中的using filesort消失了，也就是** where orderby 两个用到的顺序和数量要和索引一样 **
出现filesort的情况：
 
优化后，不再出现filesort的情况：(给 ename 加上了索引)

查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
分情况：当通过前面的查询语句 筛选大部分条件后，只剩下很少的数据。using filesort 性能影响不大。 需要综合考虑
- Using temporary
使了用临时表保存中间结果,MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by。
优化前存在 using temporary 和 using filesort 
你他妈怎么优化的? 建立索引？ 在 group by 的情况下发生的。
create index idx_deptno_ename on emp(deptno,ename) 后解决
优化前存在的 using temporary 和 using filesort 不在，性能发生明显变化：
例子二：
索引的顺序要和group by的顺序一样
3. USING index
表示相应的select操作中使用了覆盖索引(Covering Index)，避免访问了表的数据行，效率不错！ 如果同时出现using where，表明索引被用来执行索引键值的查找; 如果没有同时出现using where，表明索引只是用来读取数据而非利用索引执行查找。
覆盖索引(Covering Index)
例如：建立的索引是1 2 3 而我们查找的语句是 select 1 2 3 个数个顺序刚好匹配，就是覆盖索引。
理解方式一（重点）：就是select的数据列中用从索引中就能取得，不必读取数据航，MYSQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说查询列要被锁键的索引覆盖
理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据;当能通过读取索引就可以得到想要的数据，那就不需要读取行了 。
①一个索引 ②包含了(或覆盖了)[select子句]与查询条件[Where子句]中 ③所有需要的字段就叫做覆盖索引。
上句红字理解：
select id , name from t_xxx where age=18;
有一个组合索引 idx_id_name_age_xxx 包含了(覆盖了)，id,name,age三个字段。查询时直接将建立了索引的列读取出来了，而不需要去查找所在行的其他数据。所以很高效。
(个人认为：在数据量较大，固定字段查询情况多时可以使用这种方法。)
注意：
如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select *，
因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降。
-
Using where
表明使用了where过滤 -
using join buffer
使用了连接缓存：
出现在当两个连接时
驱动表(被连接的表,left join 左边的表。inner join 中数据少的表) 没有索引的情况下。
给驱动表建立索引可解决此问题。且 type 将改变成 ref -
impossible where
where子句的值总是false，不能用来获取任何元组 -
select tables optimized away
在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者 对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算， 查询执行计划生成的阶段即完成优化。
在innodb中：
在Myisam中：

myisam 中会维护 总行数 (还有其他参数)这个参数，所以在执行查询时不会进行全表扫描。而是直接读取这个数。
但会对增删产生一定的影响。根据业务情况决定谁好谁坏
innodb 中没有这个机制。
- distinct ：优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。
热身case
查询优化
使用索引
小案例
单表
两表
左连接，左表中的内容全部都有，所以只需要关注右表的内容，所以在右表建立索引，
右连接同理
三表
还是left join 的右边，不过这次变成了两个
重点
红色字体的被驱动表指的就是类似left jion右边，如上面的三表就需要两个。
建表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());
SELECT * FROM staffs;
ALTER TABLE staffs ADD INDEX idx_staffs_nameAgePos(name, age, pos);
案例(索引失效)
-
全值匹配我最爱
索引 idx_staffs_nameAgePos 建立索引时 以 name ， age ，pos 的顺序建立的。全值匹配表示 按顺序匹配的
EXPLAIN SELECT * FROM staffs WHERE NAME = ‘July’;
EXPLAIN SELECT * FROM staffs WHERE NAME = ‘July’ AND age = 25;
EXPLAIN SELECT * FROM staffs WHERE NAME = ‘July’ AND age = 25 AND pos = ‘dev’;
-
最佳左前缀法则
如果索引了多列，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且 不跳过索引中的列。
and 忽略左右关系 。既即使没有没有按顺序 由于优化器的存在，会自动优化。
经过试验结论 建立了 idx_nameAge 索引 id 为主键
1.当使用覆盖索引的方式时，(select name/age/id from staffs where age=10 (后面没有其他没有索引的字段条件))，即使不是以 name 开头，也会使用 idx_nameAge 索引。
既 select 后的字段 有索引，where 后的字段也有索引，则无关执行顺序。
2.除开上述条件 才满足最左前缀法则。
EXPLAIN SELECT * FROM staffs WHERE age = 25 AND pos = ‘dev’;
EXPLAIN SELECT * FROM staffs WHERE pos = ‘dev’;
-
不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描
EXPLAIN SELECT * FROM staffs WHERE left(NAME,4) = ‘July’; -
存储引擎不能使用索引中范围条件右边的列
范围 若有索引则能使用到索引，范围条件右边的索引会失效(范围条件右边与范围条件使用的同一个组合索引，右边的才会失效。若是不同索引则不会失效)
范围也用到了索引，但是用于排序，而不是检索 -
尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *
会出现 using index -
mysql 在使用不等于(!= 或者<>)的时候无法使用索引会导致全表扫描
索引 idx_nameAgeJob
idx_name
使用 != 和 <> 的字段索引失效( != 针对数值类型。 <> 针对字符类型
前提 where and 后的字段在混合索引中的位置比比当前字段靠后 where age != 10 and name=‘xxx’ ,这种情况下，mysql自动优化，将 name=‘xxx’ 放在 age ！=10 之前，name 依然能使用索引。只是 age 的索引失效)
-
is not null 也无法使用索引,但是is null是可以使用索引的
-
like以通配符开头(’%abc…’)mysql索引失效会变成全表扫描的操作
like ‘%abc%’ type 类型会变成 all
like ‘abc%’ type 类型为 range ，算是范围，可以使用索引
问题：解决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;
#drop table tbl_user
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]');
#before index
EXPLAIN SELECT NAME,age FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT id FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT NAME FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT age FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT id,NAME FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT id,NAME,age FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT NAME,age FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT * FROM tbl_user WHERE NAME LIKE '%aa%';
EXPLAIN SELECT id,NAME,age,email FROM tbl_user WHERE NAME LIKE '%aa%';
#create index
CREATE INDEX idx_user_nameAge ON tbl_user(NAME,age);
#DROP INDEX idx_user_nameAge ON tbl_user
#after index
EXPLAIN SELECT * FROM tbl_user WHERE NAME =800 AND age = 33;
-
字符串不加单引号索引失效
底层进行转换使索引失效，使用了函数造成索引失效
例如：
select * from staffs where name=‘2000’
select * from staffs where name=2000
mysql都能查出来，mysql引擎会自动做类型转换，但是索引会失效。 -
少用or,用它来连接时会索引失效
- 小总结
tip：注意上面的like kk%，和 b>4是不一样的，like的左边相当于是一个常量，右边才是%，所以相当于没有断，所以能用到三个，而下面like 的%在最左边的都不是常量，所以只能用到一个，而最后一个，不是%开头的所以还是三个
带头大哥不能死，中间兄弟不能断，索引列上无计算（手动、自动、隐式、显示），like百分加右边，范围之后全失效，字符串单引号。
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
优化总结口诀：
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
LIKE百分写最后，覆盖索引不写星。
热身case
题目SQL
【建表语句】
create table test03(
id int primary key not null auto_increment,
c1 char(10),
c2 char(10),
c3 char(10),
c4 char(10),
c5 char(10)
);
insert into test03(c1,c2,c3,c4,c5) values('a1','a2','a3','a4','a5');
insert into test03(c1,c2,c3,c4,c5) values('b1','b2','b3','b4','b5');
insert into test03(c1,c2,c3,c4,c5) values('c1','c2','c3','c4','c5');
insert into test03(c1,c2,c3,c4,c5) values('d1','d2','d3','d4','d5');
insert into test03(c1,c2,c3,c4,c5) values('e1','e2','e3','e4','e5');
select * from test03;
【建索引】
create index idx_test03_c1234 on test03(c1,c2,c3,c4);
show index from test03;
问题：我们创建了复合索引idx_test03_c1234 ,根据以下SQL分析下索引使用情况？
explain select * from test03 where c1='a1';
explain select * from test03 where c1='a1' and c2='a2';
explain select * from test03 where c1='a1' and c2='a2' and c3='a3';
explain select * from test03 where c1='a1' and c2='a2' and c3='a3' and c4='a4';
1）
explain select * from test03 where c1='a1' and c2='a2' and c3='a3' and c4='a4';
2）
explain select * from test03 where c1='a1' and c2='a2' and c4='a4' and c3='a3';
顺序不一样也能查到，因为mysql底层会自动调优转换，加入是4321，mysql底层也会
转化成1234，但是最好是一样的顺序
在一开始讲的mysql架构中有Optimizer会进行自动的转化
3）
explain select * from test03 where c1='a1' and c2='a2' and c3>'a3' and c4='a4';
索引用于范围查找 索引后面全失效，索引三个
4）
explain select * from test03 where c1='a1' and c2='a2' and c4>'a4' and c3='a3';
变化了顺序，mysql底层自动转换
所以c1='a1' and c2='a2' and c3='a3' and c4>'a4' 所以这里是四个
5）
explain select * from test03 where c1='a1' and c2='a2' and c4='a4' order by c3;
c3
作用在排序而不是查找 只有两个关联的索引，索引的功能是查找和排序，c3的作用是排序不是查找，但是不会被统计到key中，key和ref中只有c1和c2
6）
explain select * from test03 where c1='a1' and c2='a2' order by c3;
和上面的结果一样，说名字这里和c4没什么关系，因为原来能够通过msql底层自动排序，是因为range，例如c3>xx，等一会就可以了，还可以排序，可是这里的c3直接排序去了，等不到结果的，所以c4也就到不了了
7）
explain select * from test03 where c1='a1' and c2='a2' order by c4;
出现了filesort
没有c3，直接就用c4开始排序了，不可以。
8）
8.1
explain select * from test03 where c1='a1' and c5='a5' order by c2,c3;
只用c1一个字段索引，但是c2、c3用于排序,无filesort
8.2
explain select * from test03 where c1='a1' and c5='a5' order by c3,c2;
出现了filesort，我们建的索引是1234，它没有按照顺序来，3 2 颠倒了
9）
explain select * from test03 where c1='a1' and c2='a2' order by c2,c3;
10）
explain select * from test03 where c1='a1' and c2='a2' and c5='a5' order by c2,c3;
用 c1、c2两 个字段索引，但是 c2 、 c3 用于排序 , 无 filesort
explain select * from test03 where c1='a1' and c2='a2' and c5='a5' order by c3,c2;
注意在8中会出现filesort，可是这里没有出现，因为这里有c2，排序字段已经是一个常量了，所以
相当于roderby c3 ， 一个常量 ， orderby 1 有和没有无关。
本例有常量c2的情况，和8.2对比
explain select * from test03 where c1='a1' and c5='a5' order by c3,c2; filesort
11）
explain select * from test03 where c1='a1' and c4='a4' group by c2,c3;
12）
explain select * from test03 where c1='a1' and c4='a4' group by c3,c2;
Using where; Using temporary; Using filesort
group by表面上是分组，实质上是排序，分组之前必排序，唯一的不同group by有having
定值、范围还是排序，一般order by是给个范围
group by基本上需要进行排序，会有临时表的产生，因为排序的顺序发现不对，需要通过filesort，为了得到数据，先建一张临时表。
一般性建议
对于单键索引，尽量选择针对当前query过滤性更好的索引
在选择组合索引的时候，当前Query中过滤性最好的字段在索引字段顺序中，位置越靠前越好。(避免索引过滤性好的索引失效)
在选择组合索引的时候，尽量选择可以能够包含当前query中的where字句中更多字段的索引
尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的
单表查询优化
建表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;
案例
#查询 category_id 为1 且 comments 大于 1 的情况下,views 最多的 article_id。
EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
#结论：很显然,type 是 ALL,即最坏的情况。Extra 里还出现了 Using filesort,也是最坏的情况。优化是必须的。
#开始优化：
# 1.1 新建索引+删除索引
#ALTER TABLE `article` ADD INDEX idx_article_ccv ( `category_id` , `comments`, `views` );
create index idx_article_ccv on article(category_id,comments,views);
DROP INDEX idx_article_ccv ON article
# 1.2 第2次EXPLAIN
EXPLAIN SELECT id,author_id FROM `article` WHERE category_id = 1 AND comments >1 ORDER BY views DESC LIMIT 1;
#结论：
#type 变成了 range,这是可以忍受的。但是 extra 里使用 Using filesort 仍是无法接受的。
#但是我们已经建立了索引,为啥没用呢?
#这是因为按照 BTree 索引的工作原理,
# 先排序 category_id,
# 如果遇到相同的 category_id 则再排序 comments,如果遇到相同的 comments 则再排序 views。
#当 comments 字段在联合索引里处于中间位置时,
#因comments > 1 条件是一个范围值(所谓 range),
#MySQL 无法利用索引再对后面的 views 部分进行检索,即 range 类型查询字段后面的索引无效。
# 1.3 删除第一次建立的索引
DROP INDEX idx_article_ccv ON article;
# 1.4 第2次新建索引
#ALTER TABLE `article` ADD INDEX idx_article_cv ( `category_id` , `views` ) ;
create index idx_article_cv on article(category_id,views);
# 1.5 第3次EXPLAIN
EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1;
#结论：可以看到,type 变为了 ref,Extra 中的 Using filesort 也消失了,结果非常理想。
DROP INDEX idx_article_cv ON article;
关联查询优化
建表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)));
案例
# 下面开始 explain 分析
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
# 结论： type 有 All
# 添加索引优化
ALTER TABLE `book` ADD INDEX Y ( `card`);
# 第 2 次 explain
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
# 可以看到第二行的 type 变为了 ref,rows 也变成了优化比较明显。
# 这是由左连接特性决定的。 LEFT JOIN 条件用于确定如何从右表搜索行 , 左边一定都有 ,
# 所以右边是我们的关键点 , 一定需要建立索引。
# 删除旧索引 + 新建 + 第 3 次 explain
DROP INDEX Y ON book;
ALTER TABLE class ADD INDEX X (card);
EXPLAIN SELECT * FROM class LEFT JOIN book ON class.card = book.card;
建议
1、保证被驱动表的join字段已经被索引
被驱动表 join 后的表为被驱动表 (需要被查询)
2、left join 时，选择小表作为驱动表，大表作为被驱动表。
但是 left join 时一定是左边是驱动表，右边是被驱动表
3、inner join 时，mysql会自己帮你把小结果集的表选为驱动表。
mysql 自动选择。小表作为驱动表。因为 驱动表无论如何都会被全表扫描？ 。所以扫描次数越少越好
4、子查询尽量不要放在被驱动表，有可能使用不到索引。
select a.name ,bc.name from t_emp a left join
(select b.id , c.name from t_dept b
inner join t_emp c on b.ceo = c.id )bc
on bc.id = a.deptid.
上段查询中用到了子查询，必然 bc 表没有索引。肯定会进行全表扫描
上段查询 可以直接使用 两个 left join 优化
select a.name , c.name from t_emp a
left outer join t_dept b on a.deptid = b.id
left outer join t_emp c on b.ceo=c.id
所有条件都可以使用到索引
若必须用到子查询，可将子查询设置为驱动表，，因为驱动表的type 肯定是 all，而子查询返回的结果表没有索引，必定也是all
子查询优化
用in 还是 exists
优化原则: 小表驱动大表 ，即小的数据集驱动大的数据集
就像
//这个的效率要好
for(int i=5 ...){
for(int i=100000 ...){
}
}
for(int i=100000 ...){
for(int i=5 ...){
}
}
实验
有索引 大表驱动小表
select sql_no_cache sum(sal) from emp where deptno in (select deptno from dept);
select sql_no_cache sum(sal) from emp where exists (select 1 from dept where emp.deptno=dept.deptno); ##用 exists 是否存在，存在返回一条记录，exists 是作为一个查询判断用，所以 select 后返回什么不重要。
select sql_no_cache sum(sal) from emp inner join dept on emp.deptno=dept.deptno;

 


有索引 小表驱动大表
select sql_no_cache sum(e.sal) from (select * from emp where id<10000) e where exists (select 1 from emp where e.deptno=emp.deptno);
select sql_no_cache sum(e.sal) from (select * from emp where id<10000) e inner join (select distinct deptno from emp) m on m.deptno=e.deptno;
select sql_no_cache sum(sal) from emp where deptno in (select deptno from dept);

有索引小驱动大表 性能优于 大表驱动小表
无索引 小表驱动大表
select sql_no_cache sum(e.sal) from (select * from emp where id<10000) e where exists (select 1 from emp where e.deptno=emp.deptno);
select sql_no_cache sum(e.sal) from (select * from emp where id<10000) e inner join (select distinct deptno from emp) m on m.deptno=e.deptno;
select sql_no_cache sum(sal) from emp where deptno in (select deptno from dept);
 


无索引大表驱动小表
select sql_no_cache sum(sal) from emp where deptno in (select deptno from dept);
select sql_no_cache sum(sal) from emp where exists (select 1 from dept where emp.deptno=dept.deptno);
select sql_no_cache sum(sal) from emp inner join dept on emp.deptno=dept.deptno;


结论
有索引的情况下 用 inner join 是最好的 其次是 in ，exists最糟糕
无索引的情况下用
小表驱动大表 因为join 方式需要distinct ，没有索引distinct消耗性能较大
所以 exists性能最佳 in其次 join性能最差？
无索引的情况下大表驱动小表
in 和 exists 的性能应该是接近的 都比较糟糕 exists稍微好一点 超不过5% 但是inner join 优于使用了 join buffer 所以快很多
如果left join 则最慢
order by关键字优化
ORDER BY子句，尽量使用Index方式排序,避免使用FileSort方式排序
索引按照怎样的顺序建立的，orderby就按照怎样的顺序查
中间不能断
顺序不能反
建表SQL
REATE 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);
SELECT * FROM tblA;
Case
1
2
order by默认是升序的，升序之后突然降序，索引失效，所以应该同升同降
MySQL支持二种方式的排序，FileSort和Index，Index效率高. 它指MySQL扫描索引本身完成排序。FileSort方式效率较低。
ORDER BY满足两情况，会使用Index方式排序:
ORDER BY 语句使用索引最左前列
使用Where子句与Order BY子句条件列组合满足索引最左前列
where子句中如果出现索引的范围查询(即explain中出现range)会导致order by 索引失效。
尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀
小总结
order by a desc,b desc,c desc 不会出现filesort，因为是同升同降
第二种中，where a = const and b > const order by b , c 不会出现 using filesort b , c 两个衔接上了
但是：where a = const and b > const order by c 将会出现 using filesort 。因为 b 用了范围索引，断了。而上一个 order by 后的b 用到了索引，所以能衔接上 c
如果不在索引列上，filesort有两种算法： mysql就要启动双路排序和单路排序
-
双路排序
MySQL 4.1之前是使用双路排序,字面意思就是两次扫描磁盘，最终得到数据， 读取行指针和orderby列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出
多路排序需要借助 磁盘来进行排序。所以 取数据，排好了取数据。两次 io操作。比较慢
单路排序 ，将排好的数据存在内存中，省去了一次 io 操作，所以比较快，但是需要内存空间足够。从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。
-
取一批数据，要对磁盘进行了两次扫描，众所周知，I\O是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。
-
单路排序
从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出， 它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间， 因为它把每一行都保存在内存中了。 -
结论及引申出的问题
由于单路是后出的，总体而言好过双路但是用单路有问题
在sort_buffer中，方法B比方法A要多占用很多空间，因为方法B是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量，导致每次只能取sort_buffer容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取取sort_buffer容量大小，再排……从而多次I/O。
本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。 -
优化策略
增大sort_buffer_size参数的设置
用于单路排序的内存大小增大max_length_for_sort_data参数的设置
单次排序字段大小。(单次排序请求)去掉select 后面不需要的字段
select 后的多了，排序的时候也会带着一起，很占内存，所以去掉没有用的Why
提高Order By的速度
1、 Order by时select * 是一个大忌只Query需要的字段， 这点非常重要。在这里的影响是：
1.1 当Query的字段大小总和小于max_length_for_sort_data 而且排序字段不是 TEXT|BLOB 类型时，会用改进后的算法——单路排序， 否则用老算法——多路排序。
1.2 两种算法的数据都有可能超出sort_buffer的容量，超出之后，会创建tmp文件进行合并排序，导致多次I/O，但是用单路排序算法的风险会更大一些,所以要提高sort_buffer_size。
2、尝试提高 sort_buffer_size
不管用哪种算法，提高这个参数都会提高效率，当然，要根据系统的能力去提高，因为这个参数是针对每个进程的
3、 尝试提高 max_length_for_sort_data
提高这个参数， 会增加用改进算法的概率。但是如果设的太高，数据总容量超出sort_buffer_size的概率就增大，明显症状是高的磁盘I/O活动和低的处理器使用率.
分页查询的优化—limit
EXPLAIN SELECT SQL_NO_CACHE * FROM emp ORDER BY deptno LIMIT 10000,40

那我们就给deptno这个字段加上索引吧。
 
然并卵。
优化： 先利用覆盖索引把要取的数据行的主键取到，然后再用这个主键列与数据表做关联：(查询的数据量小了后)
EXPLAIN SELECT SQL_NO_CACHE * FROM emp INNER JOIN (SELECT id FROM emp e ORDER BY deptno LIMIT 10000,40) a ON a.id=emp.id
 
最后比较一下查询速度：
优化前：
 

优化后：


实践证明： ①、order by 后的字段（XXX）有索引 ②、sql 中有 limit 时，
当 select id 或 XXX字段索引包含字段时 ，显示 using index
当 select 后的字段含有 bouder by 字段索引不包含的字段时，将显示 using filesort
GROUP BY关键字优化
大致和orderby一样
group by实质是先排序后进行分组，遵照索引建的最佳左前缀
当无法使用索引列，增大max_length_for_sort_data参数的设置+增大sort_buffer_size参数的设置
where高于having，能写在where限定的条件就不要去having限定了。
去重优化
尽量不要使用 distinct 关键字去重：优化
t_mall_sku 表
id shp_id kcdz
------- ------- --------------------
3 1 北京市昌平区
4 1 北京市昌平区
5 5 北京市昌平区
6 3 重庆
8 8 天津
例子：select kcdz form t_mall_sku where id in( 3,4,5,6,8 ) 将产生重复数据，
select distinct kcdz form t_mall_sku where id in( 3,4,5,6,8 ) 使用 distinct 关键字去重消耗性能
优化： select kcdz form t_mall_sku where id in( 3,4,5,6,8 ) group by kcdz 能够利用到索引
索引优化还需要结合下一节 https://blog.csdn.net/dataiyangu/article/details/89201886