记一次SQL优化实例
问题点
由于业务场景复杂,要对多个字段进行排序且数据量较大在内存中排序显然不妥。
当前数据量关系为:
A表10w(A为主表)
B表50w (和A表相匹配数据8w)
C表50w (和A表相匹配数据4w)
…
具体的业务场景不仅三张表,这里仅举例说明
优化方案
一般对于慢sql会考虑到索引,通过执行计划Explain来观察走索引情况。
但加快SQL相应速度不仅局限于索引,而且索引的创建也不是百分百的有益处,毕竟索引也是需要维护的,加了索引对于select会提高速度,但是修改语句效率会下降。
既然索引也有弊端,那么就要从SQL本身考虑,在关联表的时候遵循小表拖动大表的原则。
小表拖动大表
可以理解成用数据量小的表去关联大的表。还是上面的例子:
A表10w(A为主表)
B表50w (和A表相匹配数据8w)
C表50w (和A表相匹配数据4w)
由于A是主表,此时有两种连接方案
1、A xxx join B xxx join C
2、A xxx join C xxx join B
分析一下两种方案:
第一种A关联B后临时表数据量为8w,再关联C的时候会用8w条数据去和C表的数据对比,再拿出相匹配的数据。
第二种A关联C后临时表数据量为4w,再用4w的数据去关联B。
综上分析,拿4w数据量和50w数据对比和8w数据和50w数据对比,显然第二种链接方案最优。
以上均个人理解,若有不对请大佬们指正~