为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】
v5.0.1
【问题描述】
同一条sql，增加了 or 条件，性能相差110倍之巨。
具体看附件。
sql1.sql (1.9 KB)
sql1执行计划.txt (22.7 KB)
sql2.sql (1.9 KB)
sql2执行计划.txt (21.7 KB)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
sql1执行计划.txt (22.7 KB)
sql2执行计划.txt (21.7 KB)
一般建议用union取代or写法
并且sql2有部分查询走到tiflash了
这边没办法使用union。
有个疑问就是 为啥加了or，性能相差这么多，并且还不走tiflash了。
关于or的性能可以参考这篇帖子
基于实践，对于未命中索引且开启TiFlash的表，会走TiFlash，不会走Tikv
可以参考官方文档：
https://docs.pingcap.com/zh/tidb/stable/use-tiflash#智能选择
想了解一下为什么没办法使用 union ？是应用程序无法这么写还是因为一些限制？
应用这边不能改写
最终解决了么？
还没有。无法改写sql，而且or按理来说也会走索引，结果并不是。性能还是相差很多
强制使用索引可以解决么？use index()
试一下，使用了 or 之后，指定 SQL 强制走 TiFlash 看下性能如何
我看2的执行计划，没有强制，执行计划已经走TiFlash了
怎么强制走tiflash呢
SELECT /*+ READ_FROM_STORAGE(TIFLASH[t1]) */ t1.a FROM t t1, t t2 WHERE t1.a = t2.a;
可以参考一下这里
https://docs.pingcap.com/zh/tidb/stable/optimizer-hints#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-
您好，你这个问题可以通过开启index merge来解决。使用方式如下：
set @@tidb_enable_index_merge = 1;
