sql 枚举_为什么你的SQL跑的比别人的慢？(上)

为什么你的SQL跑的比别人的慢？

大家有没有过这样的体验，自己的SQL一跑跑半天，别人的SQL点一下结果就出来了，难道真的是别人的运气好？一次还好说，每次都是运气好，反正我是不信。毕竟技术人都是凭实力吃饭的。

下面我们以关系型数据库mysql为例来分析SQL如何跑得更快。从数据库的本质来看SQL优化的核心就是两个方面：

具体来说

一：使用索引的优化

1. where后面的索引筛选列上不要使用函数，如substr,concat,length,数学函数等，使用了函数后原本可以走索引的查询就会变为全表扫描，这样就会极大的增加查询时间。如果我们必须要在where 条件中使用函数的话，可以采用把要过滤的值实现处理成想要的方式，举例来说：

   

2. where 后面使用多个列过滤时如果其中有索引列，则索引列必须放在where后面的第一位，如果索引列是多个列则where后面列的顺序也必须与索引列的顺序保持一致，否则是不会走索引的。

   

3. where 后面避免使用is null 或者is not null的写法，这种写法是完全不会走索引的。针对这种情况可以使用两种替代方案：

   1. 如果是单表的话可以使用EXISTS或者NOT EXISTS

      

   2. 如果是多表join的话，可以灵活使用left join,join等实现is null或者是is not null的功效。

      备注：如果在设计表的时候针对空值做了默认值填充处理，此处处理就简单多了。

4. where 后面避免使用or操作，如果确有必要推荐使用uoion all 或者union 来替换。如：

   

   如果枚举值有限的话也可以使用in，如：

   

5. where 后面避免使用not in 操作，使用not in 后会完全避开索引，需要扫描全表，极大的增加的SQL的运行时间，推荐使用exists 或者not exists来替换(也可使用join来处理)。如：

   

6. where 后面尽量避免使用!=(<>)操作符，这类操作符同样会使索引失去作用。此类操作一般可转化其他多步操作

   

7. like 后面避免使用%开头来进行模糊匹配，如果使用了同样不会再走索引。如：

二：减少数据量

1. 尽量避免使用distinct 操作，distinct 极其消耗资源且不会走索引，如果必须使用distinct 操作的话建议使用group by 替代，如：

   

2. 尽早使用where条件把不需要的数据提前过滤掉，主要针对多表join的话优先对每个表做where 的过滤操作而不是join后统一再过滤。如：

   

3. 使用union all 代替union ，由于union all 会把重复的数据过滤掉，如果需要union的数据重复性很高的话使用union all 可以极大减少数据量，进而减少IO的时间，提高查询速度。

4. 避免使用selsct * 操作，*会把所有的数据都查询出来，增大了磁盘IO，如果我们不是需要全部的列最好只select 出自己需要的列。

5. 如果查询嵌套的层次过多，中间某些临时结果集数据量过大容易造成内存溢出，甚至报错。这个时候建议先把中间的结果写入到临时表中，再使用临时表进行后面的查询操作即可。

总结：

1. 针对涉及到索引的操作，涉及到is not null,is null,<>,or,not in,like 操作时我们需要重点留意是否会影响到索引，是有有其他科替代性的操作来查询出我们想要的结果。

2. 针对减少数据量类型的优化本质上是减少IO(磁盘ID和网络ID)以及内存的使用，我们需要注意的地方是尽可能的提前过滤掉不需要的数据，以使真正参与计算的数据量尽可能的少。

说明：由于mysql的版本不断升级，官方也会尽可能的优化SQL的运行，以上只是一般性的结论，并不完全保证一定是正确的，也欢迎大家及时指正。

END