extra属性显示查询用了哪些资源，当select索引列的时候可以看到是使用了索引去查询的速度就很快
下图的查询方式虽然order_by是根据索引去排序的但是select*返回了多个列，有的列不是索引列，所以需要从磁盘中去查询，下图extra是filesort
实战中优化的一些小技巧
查询id用到主键，所以type是const，最好最快的一种，当type是all时是全表扫描最差的一种
因为log_type没有索引，所以是全表查询，性能极差
使用分页的时候加上order_by用索引列排序，也会提高查询速度，看下表type为index，如果排序字段没有索引，那么依旧是使用的全表查询
如果不加limit限制索引列使用索引去约束查询使用的还是全表查询，性能很差
凡是在展示的时候有让客户选择排序规则的字段都要设置索引
使用where 后面跟索引列加索引分页排序，会将查询类型优化成range，性能好于index
.
当分页很大的时候，用index指标去优化已经明显力不从心了，这个时候就要把指标从index提升到range，如果是要查询用户的其他信息，而且该信息不是索引列，那么这里用的是all，性能更差
比如要查询id号码排名20000之后的前20位用户id，可以看到使用的是index，因为分页达到了20000，使用index查询效率明显不够了，所以要想办法提升到range
先查询到倒序排序后第20001的数据的id，这里因为查询的是id,所以第一句sql的type为index,并且只有一条数据，所以子查询速度很快，然后使用where + order by +分页去根据索引列查询，此时的type会升级成range，查询速度更快，sql也就得到了优化
分页时带有查询条件时候的优化
当百分号在最后或者中间的时候可以使用range
当数据开头确定时%放在查询右边会使用range去查询
放中间会使用index
但是有时候文本的格式不是统一的我们无法去确认文本的开头是什么，就不能使用这种方法去查询了，这个时候应该这样做
或者使用fulltext索引 //很占空间一般不推荐，如果数据量很小可以使用
一般情况下使用第三方分词工具代替全文索引