通过之前文章准确定位到慢SQL之后，就要想办法去优化它。

SQL优化首先确定两点：节省IO成本（减少 IO 次数）、节省CPU成本（降低 CPU 计算）。

百分之90以上的时间都是IO操作所占用的，减少IO操作是SQL优化优先考虑的，order by，group by，distinct等操作都十分占用CPU资源(这些操作基本上都是 CPU 处理内存中的数据比较运算)。

想要优化SQL，我们先要明白SQL的执行顺序是怎么样的。

from最先操作，limit最后操作。所有的操作都会产生一张虚拟的表。

具体分析每一步

如何简单记忆呢，只需要记住三个词然后进行发散就好了：输入、判断、返回。

输入：from on join

判断：where判断、group by分组、having判断

返回：select输出，distinct去重、order by排序、limit返回

MySQL数据库是按照行(row)的方式存储，以一个固定大小的IO单元(被称作block或者page)来进行数据存取操作的，一般为4KB，8KB…… 大多数时候，每个IO单元中存储了多行，每行都是存储了该行的所有字段(blob等特殊类型字段除外)。

所以，我们无论取多少字段，实际上数据库在表中需要访问的数据量其实是一样的。

当还存在order by操作的时候，select子句中的字段多少会很大影响到排序效率。

避免索引失效：

1）应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。

select id from t where num is null;

可以在 num 上设置默认值 0，确保表中 num列没有 null 值，然后这样查询：

select id from t where num=0;

where字段模糊查询LIKE '%L%';是错误的，即使需要模糊查询的这个字段存在索引，引擎也不得不对所有数据逐条进行操作，LIKE 'L%';是正确的。

where字段“=”左边存在函数或者表达式，导致索引失效。WHERE F1/2=100;应改为WHERE F1=100*2;

索引：

%% like查询, not in,not exist 都无法应用索引

用了"聚合函数"查询,就无法应用索引；

复合索引,一般都是看第一个条件索引。

将计算压力转移到后台：

SELECT IFNULL(SUM(col),0) from table; // 判空

SELECT CONCAT(col, 'hello world') from table; //字段值拼接

SELECT TRIM(col) from table; // 字符串TRIM

SELECT DATE_FORMAT(col,'%d %b %Y %T:%f') from table; // 日期格式化

where子句两个要点：第一，查询条件尽量少；第二，越精确的条件,应该放在前面，先过滤掉大数据。

单表查询：去重优化，能用GROUP BY的就不用DISTINCT使用GROUP BY去重比DISTINCT效率高。

单表查询：排序优化，order by 字段加索引。

单表查询：分组优化，group by 调节顺序为复合索引顺序。

UNION ALL不执行SELECT DISTINCT函数，所以能用UNION ALL就不要用UNION，用Union ALL代替OR（比较少用，一般都用OR）。