浅谈SQL优化

索引就是一组有序的数据

  比如说我们创建索引的时候索引就已经帮我们按照一定的顺序排好队了，减少了排序的一个过程，不用整表扫描。

比如list 和set 的区别

1. 一条查询语句，那些命令比较浪费时间

自上而下的  分组（group BY）  排序（Order by）  where

1. 分组为啥浪费时间  因为分组是先排序后分组，他经历一次整体的排序后分组浪费时间
2. Order BY 为啥浪费时间 要进行一次重新的排序，浪费时间
3. Where为啥浪费时间  where不会去排序 他会对整张表的数据做循环遍历
4. 我们所进行的优化主要就是在这三个字段上做优化 避免group by Order by在工作时再次进行排序避免where对整张表做循环遍历
    

做优化之前首先了解当前的这个索引是什么样子的，首先索引是一组排好序的数据，比如说这有四个数据从大到小拍好了，排好了之后呢，每个数据上有个节点，就是将它引用，引用的是什么呢，引用的就是这个所在行的这个位置，比如我们用ID排序吧，id10就是一个数据节点，它指向一个位置，位置就id10所在的数据行，那么mysql在索引查询上呢，他根据这个地址得到10，来获取字段，

在我们做索引的时候，我们一般不做单个索引，因为这个索引是检索条件，很少会根据一个字段来做查询，我们一般会做多字段索引，所以我们一般做多字段索引的时候，一般会根据两个守则，一个是前缀守则，一个是全匹配守则，比如说我们把三个字段作为索引，那么，这三个字段如果他们的判断条件全是相当于硬的，那么这个时候他们出现的顺序不同都会导致索引失效。那么对于前缀守则呢，是我们在索引里面出现的大于等于这种关系的时候，他必须按照索引字段声明的顺序走。 怎么知道咋做的，通过explain查看该SQL语句是否应用到索引，查看type属性，是否为range属性，比这个低就不是，我们的查询语句要保证最低是range级别，要尽量往ref级别做（ref只能查询出一行数据），