黄东旭关于基础软件产品价值的思考
894
2023-04-17
聊聊国产数据库迁移中的表连接性能问题
最近很多朋友都在搞信创数据库迁移,从***迁移到国产或者开源数据库后,最大的抱怨就是性能下降太厉害,这好像和一些厂商宣称的性能不太符合。不过有时候问题也不像一些抱怨那么严重。大多数遇到性能下降的问题都是执行计划的问题,都是可以解决的,不过也有一些在***上执行计划很好的SQL,迁移到了国产数据库或者开源数据库上后,怎么调整都调不好。在开始搞信创数据库后,SQL优化将成为一件大事情。
实际上SQL最容易出问题的地方还是表连接,单表的访问,哪怕走错了索引,SQL跑的慢点了,影响还没那么严重。表连接的执行计划出问题了,可能在***上秒出的SQL,几个小时都跑不出来。这两天写了一些云山雾罩的文章,今天就写点轻松的,和大家聊聊表连接。表连接有很多种,内连接、左外连接、右外连接、全外连接、半连接(SEMI JOIN)、ANTI JOIN等。把这些连接搞清楚,把这些连接采用的连接模式搞准确,那么SQL跑起来也不至于那么让人沮丧了。
为了更好的解释今天的内容,我首先创建了两张测试表。我们今天的测试是在一个PG 12.3内核的数据库上进行。首先我们创建两张测试表,然后我们再来看看各种表连接的情况。
内连接是最常用的一种,是取两表的交集数据。典型的语法是:SELECT count(*) FROM join1 j1 INNER JOIN join2 j2 ON j1.id = j2.id;。
如果对两张表不加筛选条件,对上万条数据的JOIN,最佳的执行方式是HASH JION。从执行计划上也可以看出这一点。Inner join的等价SQL是:SELECT count(*) FROM join1 j1,join2 j2 where j1.id = j2.id;
如果我们把这条语句稍微改一下,改成SELECT count(*) FROM join1 j1,join2 j2 where j1.id <> j2.id;我们会发现这条语句的执行效率下降的很厉害,从8.3毫秒变为将近40秒了。从执行计划上看,没有使用HASH JOIN,而是使用了性能较差的NESTED LOOP。如果在某个国产数据库中因为这种情况存在无法使用HASH JOIN引发应用性能问题,在语义等价的情况下,看看是否能够使用NOT IN或者NOT EXISTS来改写,参考下面的例子。
左外连接返回的结果是整个左行源加上二者交集的部分。典型的SQL是SELECT count(*) FROM join1 j1 LEFT JOIN join2 j2 ON j1.id = j2.id;
不过我们从执行计划上看,这条SQL并没有选择left join的执行计划,而是选择了以JION2表为驱动表的右外连接。优化器认为这个执行计划效率更高。
右外连接和左外连接类似:SELECT count(*) FROM join2 j1 RIGHT JOIN join2 j2 ON j1.id = j2.id;
和上面的例子类似,优化器认为改为左外连接效果更好。
半连接SEMI JOIN和LEFT JOIN是SQL语句中两种不同的连接类型,SEMI JOIN,该语句只返回左表中包含右表中的行,并且仅返回一次。而LEFT JOIN返回左表的所有行,如果右表中没有匹配的行,则返回NULL值。其典型的SQL是:SELECT count(*) FROM join1 j1 where exists (SELECT id FROM join2 j2 WHERE j1.id = j2.id);
ANTI JOIN是排除右表的数据。典型SQL是:
SELECT count(*) FROM join1 j1 where not exists (SELECT id FROM join2 j2 WHERE j1.id = j2.id);
还有一些连接模式,比如全外连接等,我们今天就不做讨论了。最后再给大家介绍一个从***数据库迁移到国产开源数据库上最容易出性能问题的SQL:select j1.* from join1 j1,join2 j2 where j1.id=j2.id or j1.id=100;。
这条SQL的特点是在条件里出现了Or条件,在***中这条SQL的执行效率是没问题的,不过在很多国产、开源数据库中性能就出问题了。遇到这种情况,改写SQL是最终解决方法。如果在等价的情况下,我们可以用union来改写这条SQL。
select j1.* from join1 j1,join2 j2 where j1.id=j2.idunionselect j1.* from join1 j1 where j1.id=100;
今天早上写了一半有客户过来,下午又要开始出差了,今天就先写到这里吧。有些问题只是提出来了,并没有做深入的分析,只是给大家提了一个思考的方向,如果有兴趣的朋友可以再去深入分析一下。解决了这些问题,国产数据库替代的工作就会顺利很多。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。