第一要义：一定要走索引。

先明确sql的执行流程
SQL的执行顺序：from---where--group by---having---select---order by
怎么优化索引？
先跑一遍sql看时间是否符合预期，这个要排除可能出现的mysql的缓存的影响
如果真的太慢，explain查看执行计划，主要看他的type、rows、extra，然后开始针对性的加索引，但是Innodb的二级索引一般还是会存在回表的情况，而且如果有order by的操作的话说不定是filesort而不是用索引实现的。这也是很吃性能的一个点。
以下情况ORDER BY才能使用索引排序:
a)ORDER BY 语句使用索引最左前列。
b)使用Where子句与Order BY子句条件列组合满足索引最左前列。
根据最左匹配原则来写sql。
索引跟顺序有关，覆盖索引跟顺序无关
如：
最左列原则说明索引跟顺序有关
select a,b,c from table查询的结果跟实际表中a，b，c的顺序无关，而覆盖索引只是在索引上包含了a，b，c的数据而已，无需再访问数据行，故而覆盖索引跟顺序无关
，如果select中的字段实在是多，没办法进行索引覆盖。可以使用延迟关联的方式（这里我们认为每一次查询只能使用一个索引，比如可以用子查询的联合索引使用索引覆盖得到一个id列的值，而这个id列的值是另一个索引，此时外部的查询再用这个id的值来得到报表）
5.6以后的版本还会使用索引下推技术来优化查询，减少回表次数。
如果没有索引下推优化（或称ICP优化），当进行索引查询时，首先根据索引来查找记录，然后再根据where条件来过滤记录；在支持ICP优化后，MySQL会在取出索引的同时，判断是否可以进行where条件过滤，也就是说提前执行where的部分过滤操作，在某些场景下，可以大大减少回表次数，从而提升整体性能。
MySQL索引解析（联合索引/最左前缀/覆盖索引/索引下推）

1.大数据不连表查询（阿里操作手册中提到的，如果数据特别少就没必要了）
2.别用 select* ，用select +需要查询的字段，防止表结构更改（阿里操作手册）

3.limit 偏移量越大，越慢，因为他是先查出前面的值再丢掉，到最后查到需要的值再返回，比如第一条sql，先查了1000003条数据，然后丢掉了1000000条，用第二条语句优化，把指针先移到1000000，可以快很多(pagehelp可以用这个思路优化)
select * from notes limit 1000000,3;

select * from notes where id>1000000 limit 3;

4.如果确定最后数据结果只有一条，可以在最后加 limit 1，这样查到一条后就直接返回，不会遍历后面的数据了，提高效率
5.如果是连续的字段用between 1and 3 代替（1,2,3）
6.索引列设为not null，防止传入null导致全表查询

7.用 !=时不会走索引(即不等于操作，<>是一样的，也不会走)，如果字段是数字的话，可以用下面的的方式取得不等于age的数据
select id from table where age>18
union 
select id from table whereage<18

8.用like”%bcd“会导致不走索引， %在后面没事
9.mysql可能并不总会选择合适且效率高的索引去查询，这时适当的force index(indexname) 强制告诉mysql使用什么索引
在数据表大时，索引负重较大，同样的情况下，in语句里面数据条数够大时，索引会失效，可以通过force index尝试一下，不过成功的可能行很小，尽量分批去查找，批次数量可配置。
美团的慢SQL优化：
https://tech.meituan.com/2014/06/30/mysql-index.html