Using index 覆盖索引
定义：一个数据库索引（B 树）中包括全部必须查看的字段名的值，称之为覆盖索引。覆盖索引的一个特性是不用回表。
覆盖索引并不是一种索引类型，并不是一个专有名词，只是一个形容词。
下边举一个渐近的事例来叙述覆盖索引在最底层上是怎么做的：
例如，我给 col1 字段名设定了一个一般数据库索引，给id设定了主键数据库索引，应用的是innodb的表。
1.Select * from t;
全表扫描仪，在最底层主要表现为在聚集索引这棵树中把全部叶子节点一个个的载入到运行内存中，获得每一个叶连接点内的行数据信息。
2.Select col1 from t;
Mysql查验到 col1 字段名是数据库索引，因此 会立即去数据库索引获得col1字段名，由于col1数据库索引B 树中就包括col1字段名的值，不用取得叶子节点中储存的主键id值再跳到聚集索引获得col1的数据信息。这时立即寻找二级数据库索引的B 树将全部叶子节点的col1的值获得到。这一全过程只查了col1二级数据库索引的B 树，沒有去查主键数据库索引的B 树，因而这一事例就用到了覆盖索引。
3.假定现在我把col1的数据库索引删掉，再去实行 select col1from t;我想问一下会产生哪些转变 ？
大家還是要在脑壳里搭建B 树的图：
有col1数据库索引的情况下，会立即去col1的B 树中去找，而且把全部叶子节点载入到运行内存中（假定有n个叶子节点，3层，就开展了3-1 n-1=n 1次io实际操作），并在运行内存中找到每一个叶子节点的col1值。
沒有col1数据库索引的情况下，会去主键数据库索引的B 树中去找，而且也把全部的叶子节点载入到运行内存，也是发生了 n 1 次io实际操作。
仿佛没有什么差别，全是n 1次io实际操作，但确实没差别吗？
主键数据库索引的叶子节点存了全部表字段的数据信息，每一个连接点从硬盘载入到运行内存的情况下都是会把一行中全部表字段的数据信息读到运行内存。随后在运行内存中，mysql程序流程再从好几个行的好几个表字段中获得在其中的col1字段名。
col1数据库索引的叶子节点只存了col1和id这两个字段名的数据信息。每一个连接点从硬盘载入到运行内存的情况下只把col1和id的值载入到运行内存。随后只需col1，不必id。
换句话说尽管彼此之间的io实际操作频次同样，可是前面一种每一次io实际操作的速率比后面一种快，由于二级数据库索引每一个连接点的数据信息比主键数据库索引的每一个连接点的数据信息少，io读写能力的信息量不一样会危害io的速率的。
为了更好地载入col1字段名而把别的所有字段名都载入到运行内存，这就沒有采用覆盖索引，還是一个全表扫描仪。
是我试过在一个一百万的文章内容表格中实行 select title from article 查看全部title。
加title数据库索引的情况下用时0.03秒，不用title数据库索引的情况下用时56秒。
因此 不必小瞧 覆盖索引 的功效，它在特殊情景下能够产生巨大的提升。
4.Select id from t;
各自在innodb模块和myisam模块下实行这一句子，我想问一下是否有采用覆盖索引？
回答是有，由于id创建了主键数据库索引，因此 立即会去主键数据库索引的树中载入全部叶连接点的key可是不容易去载入value（主键数据库索引中期连接点的key便是id）。二种模块下都沒有回表。
5.Select id from t where col1>100;
假定我给col1加了一般数据库索引，各自在innodb模块和myisam模块下实行这一句子，我想问一下是否有采用覆盖索引？
回答是，innodb和myisam都采用了二级数据库索引查col1（type是range），可是innodb模块采用了覆盖索引，myisam没用到覆盖索引。
最先，加了标准 col1>100后，便会去col1这一二级数据库索引的树中查（而不容易立即在主键数据库索引中查）考虑 col1>100的叶子节点，innodb和myisam都必须做这一步。
可是innodb的二级数据库索引的叶子节点储存着col1的值和相匹配的id值。因而只需浏览二级数据库索引这一棵B 树就能获得到所有id，不用回表到主键数据库索引去拿id字段名。
而myisam的二级数据库索引的叶子节点中，叶子节点仅有col1，沒有id，因此 必须根据叶子节点储存的行详细地址到MYD文档中找相匹配的行，再从这种行中获取id字段名。
换句话说，innodb在这个全过程中沒有回表，而myisam发生了回表。
是我试过在一个一百万的文章内容表格中实行 select id from article where create_time > 1586421023 。
Create_time加了数据库索引，在innodb的表中查只花了0.7秒，在myisam的表中查花了31.67秒
6.Select id from t where col2>100
如今我加上了联合索引 index col1_col2 (col1,col2)。
我想问一下在innodb模块下，是不是采用了覆盖索引？
回答是采用了联合索引的覆盖索引，仅仅标准搜索沒有采用联合索引罢了（意思是 Extra中有Using index，可是type中沒有出現range只是All）。
最底层发生什么事？最先 mysql 会思索说主人家想检索id，id在主键数据库索引和二级数据库索引这两棵树上都有，但是假如在主键数据库索引中搜，为了更好地分辨col2>100这一标准，mysql会把全部叶子节点从硬盘读到运行内存，主键数据库索引的叶子节点是包括许多字段名的，这会比较慢。假如在联合索引中检索，因为col2>100不符联合索引的最左作为前缀标准，因此 mysql也会把所有叶子节点从硬盘读到运行内存，在运行内存中挑选 col2>100的连接点，并获得id字段名的值。
因此 这就是为何采用了覆盖索引，可是范畴查看没用到联合索引的缘故。
7.Select col1,col2,col3 from t where col1 > 100;
如今我加上了联合索引 index col1_col2 (col1,col2)。
我想问一下在innodb模块下，是不是采用了覆盖索引？
回答是范畴查看采用了二级数据库索引（由于where col1>100遵照了最左作为前缀标准），可是查字段的情况下因为col3没有二级数据库索引的叶子节点中，因此 必须回表到主键数据库索引的叶子节点中找col3字段名。因此 沒有采用覆盖索引。
但是由于在二级数据库索引中采用了range,因此 mysql不容易载入全部主键数据库索引的叶子节点，只是载入相匹配id的叶子节点。
8.Select col1,col2,col3 from t where col2 > 100;
这句话彻底没用到联合索引，单纯性的一个全表扫表，立即在主键数据库索引载入全部的叶连接点。Col2的标准分辨和col1,col2,col3的字段名获取全在运行内存中测算进行。
小结：不管分辨一条sql是否有采用数据库索引，是否有采用覆盖索引，都能够根据画一个B 树的图来剖析。了解最底层基本原理，sql优化越来越合情合理，不清楚最底层基本原理，sql优化就只有凭直觉。
Using FileSort 文件排序
在Sql提升中，大家期待尽量不必出現文件排序，由于出現了文件排序代表着沒有应用到数据库索引搭建好的排列，只是必须在运行内存中对字段名开展再次排列，排列的全过程是测算的全过程较为耗费cpu。
多字段名排列要尽可能遵照最左作为前缀标准，并且不必对一个字段名升序对另一个字段名降序，不然也会应用到Using filesort
假如一定会产生 Using filesort，那麼我们要掌握的文件排序有二种方法：双路排列和单路排列。
举个事例：
一个表创建的联合索引 index age_salary (age, salary)
Select * from t where id>500 and id<1000 order by salary, age;
上边的事例中：
双路排列会在二级数据库索引的B 树取下考虑where标准的行(501~999行)的salary和age字段名（不容易取别的字段名），和501~999行的详细地址表针，随后在sort buffer运行内存中排列。假如sort buffer不足（要排列的salary和age太多了），这时会建立一个 temporary table 储存結果（临时表的出現代表着更数次的io）。排净序以后再依据行表针（它是的行表针也是排好序的）回表（返回主键数据库索引）取纪录（排列的情况下只留了要排列的字段名，如今回表是要求整行的全部字段名）。
单路排列会取下考虑where标准的行(501~999行)的全部字段名（但是那样更非常容易转化成临时表，那样的话io反倒会比双路排列高），随后再sort buffer中依据salary 和 age字段名排列，随后立即輸出結果。
因为双路排列发生了回表，因此 大大增加了io频次（是单路排列的二倍，假如单路排列不转化成临时表得话）， 可是单路排列的运行内存花销更高，更非常容易在排列全过程中转化成临时表，进而提升io频次。
Mysql会依据状况挑选在其中自然一种优化算法来开展文件排序filesort。但不论是哪一种排列大家都能够根据提升 sort_buffer_size 和 max_length_for_sort_data来扩大排列缓冲区域的尺寸，减少建立临时表的很有可能。
结果：在非得出現文件排序不能的状况下，能够根据扩大排列缓冲区域的尺寸来提升
Using Temporary 应用临时表
临时表能够有大家客户手动式建立，也很有可能是在实行sql是mysql在內部建立。大家只探讨后面一种。
MySQL临时表分成“运行内存临时表”和“硬盘临时表”，在其中运行内存临时表应用MySQL的MEMORY储存模块，硬盘临时表应用MySQL的MyISAM储存模块；一般状况下，MySQL会先建立运行内存临时表，但运行内存临时表超出配备特定的值后，MySQL会将运行内存临时表导出来到硬盘临时表；
mysql会在什么时候建立內部临时表？（一般全是存储空间不足用的情况下）
A.在排列或是排序全过程中因为内存不够而造成mysql建立临时表开展附加储存。
B.在JOIN查看中，ORDER BY或是GROUP BY应用了并不是第一个表的列
C.排列或排序时，表包括TEXT或是BLOB列（那样针对单路排列来讲sort buffer毫无疑问不够）；
D.GROUP BY 或是 DISTINCT 子句中包括长短超过512字节数的列；
E.应用UNION或是UNION ALL时，SELECT子句中包括超过512字节数的列；
最终3个是立即应用硬盘临时表。
为了更好地防止应用到临时表，我们可以在排列和排序的情况下尽可能是去对数据库索引的字段名来排列排序，并且不可以让数据库索引无效。其次分拆长短较长的列，比如将Text或是Blob种类的字段名竖直分表到另一张表格中。
临时表的伤害是大大增加io频次，比较严重时造成硬盘读写能力工作压力过大。
