[项目实践-实践系列] GaussDB(DWS) 实践系列 - 震惊！复杂语句的SQL优化竟然是?

  数据库的优化犹如汪洋大海，钻研进去深不可测。 比如集群参数、SQL写法、表结构、索引等等都会对性能有直接或者间接的影响。 这里就说道说道一个关于SQL的小优化。

  在实际运用中，开发者经常会写出较为复杂的语句，例如多表关联，乃至多表关联里嵌套子查询。由于语句复杂，当语句执行缓慢乃至跑不出结果的时候，有些开发者同学会对此有些束手无策。 作者菌给小建议以供参考 – 拆分语句。

  将多表关联拆分开来，从主表开始一层层的去执行关联的语句。 首先是2表关联，查看语句执行的时间与语句数量是否因为关联键选择不当产生多对多的膨胀问题。 之后逐渐增加关联的表，来初步定为语句执行慢在何处。该思路能定为出绝大部分的问题。

  另外，在开发业务语句的时候，要逐渐积累经验，对一些SQL用法有意识的去注意，不管是GaussDB(DWS), 还是其他数据库，在不少语法上都是共通的。 例如，当业务需要判断A不存在B里面的时候， 相比not in的用法，普遍更推荐not exists。

  作者菌在帮忙一个客户的语句调优中实测， not in 客户自己原本的数据库要执行45分钟左右， 放到GaussDB(DWS)里执行了2分钟没有出结果作者菌不堪忍受就终止了语句。 在对语句进行第一轮优化后，将not in修改为了not exits， 然后只要2s时间，语句即可执行完毕！由此可见，一个小小的改变，会引来性能如此大的提升。

  开发者同学会问：哎呀作者菌，我不知道not exists比not in更好，这可怎么办呀~ 其实除了平时的积累，也可以通过执行计划进行更细致的优化哦。 在作者菌调优的案例中，not in产生的执行计划走了broadcast方式，而not exists 走了hash redistribute方式，那简单来看当然选择hash啦。 开发者同学可以通过explain + sql 来查看语句的执行计划哦。所以，请在使用DWS的过程中，也多多使用explain来对语句进行优化吧！