为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：3.0.6
- 【问题描述】：
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出打印结果，请务必全选并复制粘贴上传。
您好： 麻烦返回下两个sql的explain 和 EXPLAIN ANALYZE 的结果吗，多谢。我们看下执行计划的区别.
感谢，这个问题会尽快答复
看了一下统计信息基本上是准的，没啥问题。执行计划也没有啥大的偏差。
这两个时间上的主要差异在于：
-
union 算子那个写法，它可以分开为两个 select 选的索引，选出来的都比较优。选 pm_account 扫描量 77310，另外一个选 resp_account 索引扫描量才 947。 而在 or 的写法里面，就只能选择一种索引，最后它选择的是 create_time，这个扫描量是 415887。
-
另一个因素是 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 之后，就有可能分开考虑多个索引使用
现在还没有支持，将来可能会优化得好一些。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。