SQL中使用or性能比union性能要低好多倍

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。

您好: 麻烦返回下两个sql的explain 和 EXPLAIN ANALYZE 的结果吗,多谢。我们看下执行计划的区别.

好的,这个是union的执行计划

这个是or的执行计划

感谢,这个问题会尽快答复

看了一下统计信息基本上是准的,没啥问题。执行计划也没有啥大的偏差。

这两个时间上的主要差异在于:

  1. union 算子那个写法,它可以分开为两个 select 选的索引,选出来的都比较优。选 pm_account 扫描量 77310,另外一个选 resp_account 索引扫描量才 947。 而在 or 的写法里面,就只能选择一种索引,最后它选择的是 create_time,这个扫描量是 415887。

  2. 另一个因素是 union 算子并行的,选的两个孩子的计划都比较好并且还可以并行跑着。 而 or 的那个是一个计划,只在算子内并行(如果有非并行的算子这个场景并行程度就会比 union 吃亏)

所以最后的结果是 union 那个做出来执行更快一些。

anyway,TiDB 优化器有计划在 in、exists、union 互做等价对换,然后全局选最有执行计划吗?

正常来说,or应该也是支持索引的,tidb目前是不支持吗?

您好,这个能通过什么语法优化一下吗?因为把or换成union,编写SQL的时候会变复杂

您好,这类问题已经在设计开发中https://github.com/pingcap/tidb/issues/9019,会在以后的版本实现. 目前可能改sql,或者您测试一下use index 强制走索引是否可行?

use index没有生效,而且比较麻烦。期待贵司大佬早日解决这个问题

感谢反馈,敬请关注官网的最新动态消息~~~

在没有做完 index merge feature 之前,只能一个索引一个索引考虑,要么选要么不选

实现 index merge 之后,就有可能分开考虑多个索引使用

现在还没有支持,将来可能会优化得好一些。