查询优化
1、explain查询分析器，查看执行计划
2、索引的设计
3、慢查询日志，调试环境可以开启
4、查询缓存，区分业务，不经常变更的业务可以开启
show global status like 'QCache%';
show global status like 'Com_select';
查询缓存命中率 = Qcache_hits/(Qcache_hits + Com_select)，
查询缓存命中率多大才是好的命中率，需要具体情况具体分析。
推荐一个指标：”命中和写入“的比率，即Qcache_hits和Qcache_inserts的比值。
根据经验来看，当这个比值大于3：1时通常查询缓存是有效的，如果能达到10：1最好
索引设计
1、在经常用作where条件和group/order by的字段上建立索引
2、最左前缀匹配原则
3、尽量选择区分度高的列作为索引
4、索引列不能参与运算，如date(update_time) 这样是用不到索引的
5、尽量扩展索引，不要新建索引
索引最左匹配原则
mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配
比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。即，组合索引的第一个字段必须出现在查询组句中，这个索引才会被用到。
解释：(a,b,c,d)的索引，索引匹配顺序a-b-c-d，而由于where c >3停止匹配，所以d就用不到索引了
(a,b,d,c)的索引，索引匹配顺序a-b-d-c，为何可以用到d了呢，注意最左匹配说的是索引的匹配，并不是where条件的顺序
设计优化
1、数据库字段的设计，适度冗余字段，避免join
2、做分库分表
3、分库分表的ER表的设计，例如order-orderdetail，同一个订单号落在同一个库中
4、跨库join，通过建立全局表，冗余字段来避免
EXPLAIN
possible_keys：表示搜索可能用到的索引
key：表示实际选用的索引，如果没有选择索引,是NULL
有一种可能是possible_keys为空，但是key不为空的情况。
这种情况下说明mysql无法利用索引来搜索数据，但是返回的列却是某个索引的一部分，因此可以用覆盖索引的方式优化全表扫描。
https://ruby-china.org/topics/27022 末尾的评论
key_len:显示MySQL决定使用的键长度,如果键是NULL,则长度为NULL
如，字段a(int 4) b(int 3)，查询时只用到复合索引(a,b)中的a，则key_len=4，实际使用的键的字节长度，若两个都用到了key_len=7
rows:显示MySQL认为它执行查询时必须检查的行数。多行之间的数据相乘可以估算要处理的行数。
ref:ref列显示哪些列或常量与键列中指定的索引进行比较，即显示索引的哪一列被使用了
type：连接类型
从最好到最差的连接类型为 const、eq_reg、ref、range、index和ALL
const:最多有一行匹配，如使用RIMARY KEY or UNIQUE index作为条件查询时
eq_ref:对于每个来自于前面的表的行组合,从该表中读取一行。除了system（只有一行）和const类型，这是最好的连接类型。
ref:对于每个来自于前面的表的行组合,所有有匹配索引值的行将从这张表中读取
..
index:该联接类型与ALL相同,除了只有索引树被扫描。这通常比ALL快,因为索引文件通常比数据文件小。
ALL:对于每个来自于先前的表的行组合,进行完整的表扫描。
filtered:显示了通过条件过滤出的行数的百分比估计值
参考：
https://tech.meituan.com/mysql-index.html
https://www.zhihu.com/question/36996520
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
http://blog.csdn.net/mccand1234/article/details/66475382
http://overtrue.me/articles/2014/10/mysql-explain.html
https://ruby-china.org/topics/27022