示例数据使用的是mysql官方提供的sakila数据库
SQL语句优化
in语句与like语句优化
在sql查询中一般不推荐使用in进行查询，使用instr函数进行like或者in查询
xxx为传入参数
常规模糊查询：like '%xxx%'
intsr函数模糊查询：instr(name,'xxx') > 0
instr(name,'xxx') > 0 等价于 like '&xxx&'
[转] ORACLE中Like与Instr模糊查询性能大比拼
这篇文章中我们可以发现，使用instr函数进行like查询效率会得到优化
select * from A where id in(select id from B)
这种in语句查询可以优化为
select a.* from A a where exists(select 1 from B b where a.id=b.id)
A表数据与B表数据相差不大时，in和existsx效果相差，B表数据越多,越适合exists()发挥效果。
Max()优化
下面这条sql语句是查询payment表中patment_date列最大的值。
SELECT MAX(payment_date) FROM payment
可以看到我们这条sql耗时0.016s，当前这张表的数据量只有16049行，当表中的数据量很大时，这个查询就会非常耗时，所以我们建立一个覆盖索引（建立的索引包含了我们查询的所有列称为覆盖索引）
create index idx_payment on payment(payment_date);
再执行
执行耗时变为了0s
count()优化
首先讲一下count(*)与count(列)的区别，count(*)会统计该表所有的行,count(列)只会统计这个列不为null的行
下面这个例子中，要求同时查询出2006年和2007年电影的数量。（2006与2007的数量需要分开，不能用2006和2007的总和）
错误的方式：没有将2006和2007的数据分开。
正确的方式：
SELECT COUNT(release_year='2006' OR NULL ) AS '2006',COUNT(release_year='2007' OR null) AS '2007' FROM film
子查询优化
通常情况下，需要把子查询优化为join查询，但要注意关联键是否有一对多的关系，如果有则可能造成重复数据。
下面这个例子中，t表通过子查询t1表查询t1.id中含有t.id的数据。
select t.id from t wnere t.id in (select t1.id from t1);
改写后的sql：
select t.id from t join t1 on t.id=t1.id;
如果存在数据重复，我们就不得不用distinct去重：
select distinct t.id from t wnere t.id in (select t1.id from t1);
group by优化
group by可能会出现临时表（Using temporary），文件排序（Using filesort）等，影响效率。
可以通过关联的子查询，来避免产生临时表和文件排序，可以节省io。
如果我们需要对关联查询中的某一列进行group by的话，那么我们最好选用同一表中的列来进行group by。
下面这个例子中，我们查询出每一个演员所参演的影片的数量，我们关联了演员表（actor）和演员与影片的关联表（film_actor）关联键为演员ID（actor_id），这里我们将actor_id进行group by。
select actor.first_name,actor.last_name,count(*) from film_actor inner join actor USING(actor_id) GROUP BY film_actor.actor_id
using()用于两张表的join查询，要求using()指定的列在两个表中均存在，等价于join的on;
例如: select a., b. from a left join b using(colA);
group by 的列尽量要使用在有索引的列上,否则就会使用临时表和文件。
改写后的sql:
select actor.first_name,actor.last_name,c.cnt from actor
inner join (select actor_id,count(*) as cnt from film_actor group by actor_id) as c
using(actor_id);
先关联子查询，查询出了每个演员的影片数量，然后通过跟演员表关联，查询演员的名称
limit优化
limit常用与分页处理，时常伴随order by使用，因此大多使用文件排序,或者文件过滤。
下面这个例子中，我们使用title进行排序，并且查询第50行开始的5行记录。
SELECT film_id,description FROM film ORDER BY title LIMIT 50,5
- 优化步凑一：使用有索引的列或主键进行order by操作，直接使用主键或索引进行排序可以避免大多IO操作
SELECT film_id,description FROM film ORDER BY film_id LIMIT 50,5
随着我们翻页越来越往后，IO操作实际上是越来越大的，如果我们的数据是几百万行几千万行，翻页到后面响应速度是非常慢的，所以我们有必要对sql进一步优化。
- 优化步凑二：记录上次返回的主键，在下次查询时使用主键过滤。
SELECT film_id,description FROM film where film_id>50 and film_id<60 ORDER BY film_id LIMIT 1,5
这样使用的效率是固定的，不会因为翻页到后面影响速度，但这样的弊端就在于，要求主键一点要自增并且连续的。
SQL语句优化的思想在于数据量大时避免过多的扫描记录。
索引优化
- 如何选择合适的列建立索引？
1.在where、group by、order by、on中出现的列。
2.索引字段越小越好。
3.离散列大的列放到联合索引前面。
下面这个例子中，我们来说明如何判断列的离散度。
通过sql语句：
select count(distinct colA),count(distinct colB) from table
如果count(distinct colA)大于count(distinct colB)则说明colA的离散度更高，所以我们在创建联合索引是应该将colA 放在最左:index(colA,colB)。
- 索引是否越多越好？
通常情况下，建立索引可以优化查询效率，但是会降低写入效率。
但实际上呢，过多的索引不但会影响写入效率同时也会影响查询，这是由于数据库在进行查询、分析的时候首先要选择使用哪个索引来进行查询，我们的索引越多这个选择的过程就越慢。
- 索引的维护及优化——重复及冗余的索引
重复索引是指相同的列以相同的顺序建立同类型的索引，例如primary key和unique。
冗余索引是指多个索引的前缀列相同，或是在联合索引中包含了主键的索引。
- 重复及冗余索引的查找
进入到information_schema数据库运行下面的sql
SELECT
a.TABLE_SCHEMA AS '数据库名' ,
a.TABLE_NAME AS '表名' ,
a.INDEX_NAME AS '索引1' ,
b.INDEX_NAME AS '索引2' ,
a.COLUMN_NAME AS '重复列名'
FROM
STATISTICS a
JOIN STATISTICS b ON a.TABLE_SCHEMA = b.TABLE_SCHEMA
AND a.TABLE_NAME = b.TABLE_NAME
AND a.SEQ_IN_INDEX = b.SEQ_IN_INDEX
AND a.COLUMN_NAME = b.COLUMN_NAME
WHERE
a.SEQ_IN_INDEX = 1
AND a.INDEX_NAME <> b.INDEX_NAME
结果如下：
结果表明在keke_beauty数据库中的sys_user表中，字段id拥有重复的索引，primary以及unique。
