前言
如果要写出优质的SQL语句，就需要了解MySQL的存储原理。MySQL是如何分析SQL，如何利用索引查询。
Explain 关键字
explain select * from ic_base; --查看SQL的执行情况
id: 执行编号，标识Select的执行顺序，存在子查询等负责查询的时候用来标识执行的优先顺序。
select_type: select查询语句的类型（simple，primary，subquery，derived，union，union result，dependent union，dependent subquery）。
> simple : 简单SQL
> primary : 包含union或者子查询，最外层的部分标记为primary
> subquery : 非相关子查询（子查询和主表之间有关联关系）
> derived : 派生表——该临时表是从子查询派生出来的，位于form中的子查询
> union : 包含union 或者 union all 的查询
> union result : MySQL建立的临时表需要去掉重复数据
> dependent union : 顾名思义，首先需要满足UNION的条件，及UNION中第二个以及后面的SELECT语句，同时该语句依赖外部的查询
> dependent subquery : 相关子查询（子查询和主表之间有关联关系）
> materialized :当查询优化器在执行包含子查询的语句时，选择将子查询物化之后与外层查询进行连接查询。
table: 访问的表名
partitions: 分区信息
type: 访问类型（system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL），innodb中不存在system.一般来说，得保证查询至少达到range级别，最好能达到ref。
> system : 这是const连接类型的一种特例，表仅有一行满足条件
> const : 仅有一行满足条件
> eq_ref : 最多只返回一条符合条件的记录。使用唯一性索引或主键查找时会发生
> ref : 索引访问，等值匹配或者常量匹配。
> ref_or_null : 索引访问，等值匹配或者常量匹配，存在null值。
> index_merge : 合并索引，有多个索引可以选择。
> unique_subquery : 子查询使用唯一索引
> index_subquery : 子查询使用索引
> range : 范围扫描，一个有限制的索引扫描。key列显示使用了哪个索引。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN 和IN 操作符,用常量比较关键字列时。
> index : 和全表扫描一样。只是扫描表的时候按照索引次序进行而不是行。主要优点就是避免了排序, 但是开销仍然非常大。
> ALL : 全表扫描
possible_keys: 显示能够使用的索引
key: 使用的索引
key_len: 使用的索引长度（使用的索引字段长度之和）
ref: 关联列或者常数
rows: 数据行数（来自统计信息）
filtered: 过滤百分比，可能满足条数/总条数
Extra: MySQL的补充额外信息
> no tables used : 没有额外信息
> Using where : 当我们使用全表扫描来执行对某个表的查询，并且该语句的WHERE子句中有针对该表的搜索条件
> Using index: 当我们的查询列表以及搜索条件中只包含属于某个索引的列，也就是在可以使用索引覆盖的情况
> Impossible where: 查询语句的WHERE子句永远为FALSE时将会提示该额外信息
> Using index condition: 有些搜索条件中虽然出现了索引列，但却不能使用到索引
> no matching min/max row: 当查询列表处有MIN或者MAX聚集函数，但是并没有符合WHERE子句中的搜索条件的记录
> Using join buffer(block nested loop) : 在连接查询执行过程中，当被驱动表不能有效的利用索引加快访问速度，MySQL一般会为其分配一块名叫join
buffer的内存块来加快查询速度
> Using filesort : 很多情况下排序操作无法使用到索引，只能在内存中（记录较少的时候）或者磁盘中（记录较多的时候）进行排序，这种在内存中或者磁盘上进行排序的方式统称为文件排序（英文名：filesort）
> Using temporary : 在许多查询的执行过程中，MySQL可能会借助临时表来完成一些功能，比如去重、排序之类的，比如我们在执行许多包含DISTINCT、GROUP BY、UNION等子句的查询过程中，如果不能有效利用索引来完成查询，MySQL很有可能寻求通过建立内部的临时表来执行查询
> start temporary , end temporary: 查询优化器会优先尝试将IN子查询转换成semi-join，而semi-join又有好多种执行策略，当执行策略为DuplicateWeedout时，也就是通过建立临时表来实现为外层查询中的记录进行去重操作时，驱动表查询执行计划的Extra列将显示Start temporary提示，被驱动表查询执行计划的Extra列将显示End temporary提示
> FirstMatch(表名) : 在将In子查询转为semi-join的去重的方式（找到一条就返回）
查询优化器
set optimizer_trace="enabled=on"; --打开查询优化器
---------------需要执行的SQL（可以使用explain）-------------------------
select * from information_schema.OPTIMIZER_TRACE --查询优化器的执行结果
set optimizer_trace="enabled=off"; --关闭查询优化器
查询优化器查询的结果
query: 对应SQL.
trace : 优化过程（里面有行估算，走索引，最左前缀等一些计算成本的过程，然后MySQL自动选择一种最优方式）。
成本计算公式：全表扫描的公式： 主键索引页数*1 + 行数*0.2 = Data_length/16K + Rows*0.2 ; 主键索引页数，行数来自统计信息， 其他数据为MySQL固定常量
由于MySQL的成本计算也是估算（99%是靠谱的），但是当遇到很复杂的SQL，或者统计信息与实际情况差距太大的时候，会导致MySQL的优化过程出现问题。
这个时候我们需要干扰MySQL的执行计划，强制走我们需要的索引或者更新统计信息。
实战
一、ANALYZE TABLE ic_base; -- 重新收集ic_base 的统计信息，保证MySQL优化器计算准确。
二、hints
USE INDEX：限制索引的使用范围，们在数据表里建立了很多索引，当MySQL对索引进行选择 时，这些索引都在考虑的范围内。但有时我们希望MySQL只考虑几个索引，而不是全部的索引， 这就需要用到USE INDEX对查询语句进行设置。
IGNORE INDEX ：限制不使用索引的范围
FORCE INDEX：我们希望MySQL必须要使用某一个索引(由于 MySQL在查询时只能使用一个索 引，因此只能强迫MySQL使用一个索引)。这就需要使用FORCE INDEX来完成这个功能。
hints 语法：
SELECT * FROM table1 USE|IGNORE|FORCE INDEX (col1_index,col2_index) WHERE col1=1 AND col2=2 AND col3=3;
三、straight_join -- 强制改成左边为驱动表
select t1.* from Table1 t1 STRAIGHT_JOIN Table2 t2 on t1.CommonID = t2.CommonID where t1.FilterID = 1
总结
SQL优化伴随开发的全部过程，随着时间和业务的推移，一些SQL的性能跟不上了，需要重新整理和优化。
笔者遇到过好几千行的SQL（union,子查询，嵌套查询，函数，分组，排序）几乎用了SQL的全部特性，优化这类SQL第一要熟悉SQL的作用，第二点要将这类SQL拆小，先找到慢的地方，然后再考虑优化。优化SQL是一个需要耐心的活，平时一定要注意SQL写法，尽量避免一些糟糕的写法，减少后期的维护。