80%的Sql提升全是根据合理使用数据库索引就能进行的。
合理使用数据库索引代表着要创建数据库索引而且不许数据库索引无效。怎样防止数据库索引无效
A.尽可能用全值配对
B.尽可能考虑最左作为前缀标准
C.没有数据库索引列上做一切的实际操作（测算、涵数、全自动或手动式变换种类）
D.对数据库索引按范畴标准搜索的实际操作尽量放到最终，由于范畴做为标准以后的标准不容易采用数据库索引
E.尽可能应用覆盖索引，少用select *
F.对数据库索引字段名应用 != 的情况下数据库索引会无效
G.Is null，is not null 会数据库索引无效
H.Like “%…%”模糊匹配会数据库索引无效（like “xxx%”会采用数据库索引，type浏览种类为range）
I.字符串数组不用单引号会数据库索引无效
J.用where … or… 会数据库索引无效
实际事例剖析：
记牢一句话，剖析一个sql是否有采用数据库索引，一定要先绘图，在脑壳里画一个B 树的图，随后用我还在Mysql数据库索引篇的第二篇文章内容中的划线法去认证。
事例1：
CREATE TABLE `t` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`col1` int(11) DEFAULT NULL,
`col2` int(11) DEFAULT NULL,
`col3` int(11) DEFAULT NULL,
`extra_file` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `ccc` (`col1`,`col2`,`col3`)
) ENGINE=InnoDB
explain select * from t where col1=3 and col2=12 and col3=11; # 3个字段名都采用数据库索引
explain select * from t where col2=12 and col3=11; # 没用到数据库索引
explain select * from t where col2=12 and col3=11 and col1=3; # 3个字段名都采用数据库索引。仅仅把col1放进后边，和第一句彻底没差别，mysql还不会笨到把标准的部位换一下就数据库索引无效。（实际上是mysql的查看优化器optimizer会对sql句子开展调节把它变成了where col1=3 and col2=12 and col3=11）
explain select * from t where col3=11 and col1=3; # 仅有col1采用数据库索引，col3=11只有直到把叶子节点的数据加载到运行内存后再用查找算法搜索了
explain select * from t where col2>11 and col1=3; # col1和col2都采用数据库索引
explain select * from t where col2=11 and col1>3; # col1采用了数据库索引
explain select * from t where col1=13 and col2>15 and col3=10; # 仅有col3没用到数据库索引
Explain select * from t where id<15 and col1>17; # id采用了主键数据库索引，可是col1没用到。由于where以2个数据库索引为标准，mysql不太可能对一个查看另外应用2个单独的数据库索引，因此 会挑一个高效率高些的数据库索引。而id是主键数据库索引，是一个聚集索引，数据库索引和数据信息关联在一块，而col1坐落于一个二级数据库索引，假如用了二级数据库索引还得再去主键数据库索引查。因此 自然优先选择应用id数据库索引。剖析这条句子的情况下，脑海中里应当闪过出一个主键数据库索引的b 树和一个二级数据库索引的b 树。
explain select * from t where col1<13; # 沒有采用数据库索引，全表扫描仪，由于尽管合乎最左作为前缀标准，可是考虑col1<13标准的总数有25条，占了25/45=5/9 占了一半之上，并且也要依据二级数据库索引相匹配的主键再到主键数据库索引的B 树中找相匹配的数据信息。因此 mysql觉得还比不上全表扫描仪的快，因此立即全表扫描仪。实际上是由于我这个表仅有45行，信息量较为少，如果是在一个几千几万行的表中就不容易那样。
select id from t where col1<13; # col1采用了ccc数据库索引（type是一个range），并且还采用了覆盖索引（using index）。
Select * from t where col1 = 10 and col2 like “kk%” and col3 = 14 # col1,col2都采用了数据库索引，col3没用到
Select * from t where col1 = 10 and col2 like “%kk%” and col3 = 14 # col1采用了数据库索引，col2,col3没用到
Select * from t where col1 = 10 and col2 like “k%kk%” and col3 = 14 # col1,col2都采用了数据库索引，col3没用到
事例2：
還是应用事例1中的数据信息和数据库索引。下边不仅要讲出是否有应用数据库索引，也要讲出这些字段名用了数据库索引，用以排列還是搜索。
Explain select * from t where col1 = 15 and col3=20 order by col2 # col1采用数据库索引的搜索，col2采用了数据库索引的排列，沒有出現using filesort，col3沒有采用数据库索引（当where和order另外出現的情况下，首先看where后看order。在col1是15的状况下，col3是乱序的；因此 会将考虑col1=15的行全看到运行内存，随后运行内存再挑选出col3=20的行，因为这种行的col2在col1=15的状况下到树中早已安排好序，因此 不容易再再运行内存中排列，因此 col2采用了数据库索引的排列）
Explain select * from t where col1 = 15 order by col3 # col1 采用了数据库索引的搜索，col3没用到排列，会在运行内存中对col3排列，出現了using filesort
Explain select * from t where col1 = 15 order by col2,col3 # col1 采用了数据库索引的搜索，col2和col3采用了数据库索引的排列，没出現 using filesort
Explain select * from t where col1 = 15 order by col3,col2 # col1 采用了数据库索引的搜索，col2和col3都没用到数据库索引的排列，出現 using filesort，运行内存时会对行开展2次排列，一次对col3排列，再对col2排列。
Explain select * from t where col1 = 15 and col2= 20 order by col3,col2 # col1采用了数据库索引的搜索，col2也采用了搜索，col3也采用了数据库索引的排列（結果集中化col2统统是20，对col2还排个鬼的序呀）
Explain select * from t where col1 = 15 group by col2,col3 # col1采用了数据库索引的搜索，col2和col3采用了数据库索引的排列
Explain select * from t where col1 = 15 group by col3,col2 # col1采用了数据库索引的搜索， c3 和 c2都没用到数据库索引的排序功能
难度系数升級：
Explain select * from t where col2 > 20 order by col1 # 查询条件违背了最左作为前缀标准，这时不容易走二级数据库索引，只是立即走主键数据库索引开展一个全表扫描仪。主键数据库索引中的 col1是乱序的，因此 order by col1会在运行内存中开展排列，而没法采用数据库索引B 树的排列，因此 会出現 Using filesort。
一个sql是走二级数据库索引還是走全表扫描仪，关键看where句子，并不是看order by句子。上边的where句子中，col2是一个乱序的（col1同样的连接点下的col2才算是一个井然有序的）因此 col2>20压根用不上二级数据库索引，因此 会去走全表扫描仪。
還是这句话，脑壳里进行一个B 树的手稿才可以剖析。
Explain select col1,col2,col3 from t where col2>20 order by col1 # 尽管where标准每遵照最左作为前缀，可是select后跟的字段名全在二级数据库索引的树中，并且沒有别的不必要的字段名，因此 会采用覆盖索引，采用覆盖索引肯定是走二级数据库索引不动聚集索引啦。随后，首先看where，col2>20违背了最左作为前缀标准，因此 会扫描仪全部二级数据库索引的叶子节点到运行内存中去挑选考虑col2>20的行；考虑col2>20的行的col1是排好序的，因此 不容易再在运行内存中对col1排列。因此 ，采用了 Using index 覆盖索引，可是沒有Using filesort。但是，col2>20这一标准的分辨挑选会在运行内存中产生，因此 ，type并不是range只是index。
Explain select col1,col2,col3 from t order by col1 asc , col2 desc # col1采用了数据库索引的排列，由于二级数据库索引中col1自身便是排好序的，可是 col1同样的叶连接点下的col2是一个升序排列的，假如你期待把他变成降序就只有在运行内存中再次排了。因此 采用了Using filesort
假如 order by col1 desc , col2 desc 那么就都采用了数据库索引的排列。
小小结：
一个字段名采用了数据库索引的排序功能时，它的益处是防止了mysql在运行内存中对这一字段名排列，降低测算量而提升特性（在运行内存中排列的全过程是一个cpu密集式实际操作），反映在explain中便是沒有Using filesort的出現。
上边的事例2中的句子
假如sql句子中出現order by A，可是A字段名没用到数据库索引的排序功能，便会出現 using filesort
假如sql句子中出現group by A，可是A字段名没用到数据库索引的排序功能，便会出現 using filesort 和 using temporary。
排序的前提条件是排列，因此 剖析group by 的情况下只需把它当做order by来剖析就可以。
事例3：用遮盖索引优化 like “%…%”
如今有一个100w数据信息的innodb文章内容表，我要做依据搜索关键词文章内容的，比如，在输入框检索“金融投资”，就可以把带有金融业关键字的题目的文章内容按发布时间字段名倒序排列查出来全部字段名，我只看一遍30篇。
一开始，仅有主键id有数据库索引。
版本号1:
Select * from arts where title like “%金融投资%” order by create_time desc limit 30;
剖析：这是一个全表扫描仪，mysql会一个一个的把主键数据库索引的叶连接点从硬盘载入到运行内存，并在运行内存用字符串数组搜索的方法找title是不是有“金融投资”这一关键词。Mysql载入够30条符合条件的行后，便会终止载入后边的叶连接点。
因此 假如包括“金融投资”的文章内容恰好放到100W个数据信息的前1000条，那麼祝贺你了，搜索的時间会很短，可是假如这种文章内容集中化在100W个数据信息的最终1000条，那麼大部分你类似实行100W次io，真实的解析xml了全部表。
用这一sql查了我整整的一分多钟。
为了更好地促使where title like “%xxx%” 不产生全表扫描仪，我们可以应用遮盖索引优化。
版本号2：
创建一个联合索引 index ct_title (create_time, title)
分几句sql去查：
Select id from arts where title like “%金融投资%” order by create_time desc limit 30;
应用了覆盖索引。并且沒有出現 Using filesort ，表明order by create_time排列也采用了数据库索引的排列，沒有在运行内存中开展排列。
最底层发生什么事事呢？最先，mysql把联合索引的全部叶连接点从左往右一个个的从硬盘读进运行内存，并在运行内存搜索title是不是包括“金融投资”关键词。直至寻找30个的情况下，终止载入，可是假如没找到30个，便会一直往下读取下一个叶连接点直至把叶子节点所有看完（可是这一全过程迅速，由于二级数据库索引的叶连接点只存着数据库索引值和id值）。
那样就获得到30个符合条件的文章内容的id。
Select * from arts where id in (刚查出的文章内容id)。
这个时候，便会往聚集索引的树中去逐一对每一个id从根节点向下寻找叶子节点，倘若树仅有3层，这句话sql也就一个共发生了 (3-1)*30 = 60次sql。
这几句合起來一共就花了0.3秒。
别这样写，由于子查询不能用limit
select * from arts where id in (Select id from arts where title like “%金融投资%” order by create_time desc limit 30);
之上事例中，事例1科学研究了精准配对和范畴配对下是不是应用了数据库索引，事例2科学研究了排列和排序是不是应用了数据库索引，是不是有using filesort 文件排序的出現，事例3科学研究了using index 覆盖索引。
可是，以不变应万变，只需并不是繁杂的关联查询或是子查询，画一个B 树的手稿来剖析，一切难题得到解决。
=============================================================
SQL提升提议：
1.Insert提升
用一个insert插进好几条数据信息（批量插入）。
依照主键次序插进
应用手动式递交事务管理
2.Order by提升
Order by后边的排列字段名尽可能依照建联合索引时的字段名次序来放（遵照最左作为前缀标准），进而绕开文件排序(Using filesort)。假如如果可以的话最好是可用上覆盖索引（Using index），但是非得采用覆盖索引得话select 查的字段名只有是数据库索引的字段名了。
针对多字段名排列：遵照最左作为前缀标准，并且不必对一个字段名升序对另一个字段名降序，不然也会应用到Using filesort（要不都升序排列，要不都降序排列）。
假如一定会产生 Using filesort，那麼能够根据提升 sort_buffer_size 和 max_length_for_sort_data来扩大排列缓冲区域的尺寸，减少建立临时表的很有可能。
我再总结一下order by的提升：
遵照最左作为前缀标准,绕开文件排序,最好是可用上覆盖索引
不必对一个字段名升序对另一个字段名降序
假如一定会产生文件排序，能够扩大排列缓冲区域的尺寸，减少建立临时表的很有可能。
3.Group by提升
Group by是会先开展排列后排序的。因此 全部能用以order by的提升都能够用以group by
如果我们只为排序无需排列，就可以应用order by null;
Select age, count(age) from t group by age order by null
4.子查询提升
尽可能用多表联查来替代子查询；你能用explain剖析一下用子查询和用join联查的区别
5.Or 提升
Or的上下两侧都务必是数据库索引字段名，并且or两侧尽可能不必是复合型数据库索引的2个字段名，不然都是会造成数据库索引无效变为一个全表扫描仪（最好or两侧全是同一个字段名的标准或是是2个列项数据库索引）。
尽可能用union替代or
你能比照一下
Select * from t where id=1 or id = 10;
Select * from t where id=1 union select * from emp where id = 10;
前面一种是一个type为range的查看，后面一种是两个type为const的查看
Select * from t where id=1 or age = 20;
Select * from t where id=1 union select * from emp where age = 20;
前面一种是一个type为 index_merge , 后面一种是一个type为const和ref的查看。
6.Limit分页查询提升
伴随着偏移的提升，limit的查看高效率越低，limit 20w,10会扫描仪200w零10条纪录，但只回到200w到200万零10这10条数据信息。
提升1：能够采用覆盖索引，如今二级数据库索引上获得分页查询的id，再依据二级数据库索引上的id寻找聚集索引查看所必须的的别的列內容
如： select * from t order by create_time limit 20w, 10; (create_time)加了数据库索引
提升为：
Select * from t t join (select id from t order by create_time limit 20w, 10) a where t.id=a.id
一个是全表扫描仪All ，一个是覆盖索引 index
提升2：假如的分页查询是依据id排列的,并且id沒有断块，那麼能够先获得200w页的最后一个id，随后依据这一id往后面查10条。
Select * from t where id>200w limit 10;
7.大批量插入数据信息的提升（一次性插进一百万或1000万的数据信息）
针对innodb来讲，充分考虑B 树的结构，在插进数据信息的情况下应当按主键次序由小到大插进，主键种类挑选自增的整形。应用整形是为了更好地减少数据库索引占有的储存空间，减少非叶子节点中每一个原素的尺寸，促使一个非叶子节点可以容下大量的数据库索引，促使在B 树占有室内空间尺寸同样的状况下这棵树的叠加层数更少。而按由小到大的插进能够降低搭建B 树全过程中页瓦解的频次，提升插进高效率。
关掉唯一性校检： set unique_checks = 0; 插进完毕后能够把它设定会1。
手动式递交事务管理： set autocommit=0; 每插进2w条数据信息手动式递交1次。插进进行后在设定回1。
用一个insert指令插进好几条数据信息。
