TiDb中SQL优化，在MySQL中执行正常，在TiDb集群下执行很慢

[TiDBer_ly0m6BIW]

【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.5.1
【复现路径】
在TiDb中执行以下SQL需要8秒左右，但是在MySQL 中执行600毫秒左右。TiDb 集群配置整体由于MySQL

SELECT * FROM tr_entrust
where Id in (select TestId from tr_testitems where ReportNo like '%jsc%' or TaskNo like '%jsc%') or EntrustNo like '%jsc%'

在TiDb 中的执行计划

在MySQL中的执行计划

针对这样的问题有什么优化方式吗？

[xfworld (魔幻之翼)]

修改下索引吧，

最下面两个表的查询，均是全表扫描，数据越多就会越慢了

索引一个都没命中…

[TiDBer_5cwU0ltE]

MySQL里的用了执行计划， tidb还是全表扫描。 这样的情况下，检查下索引情况吧，是不是tidb上没有对应索引呀。

[TiDBer_ly0m6BIW]

应该不是索引问题，把上面的SQL改为如下形式，执行速度正常

explain analyze SELECT * FROM tr_entrust
where Id in (select TestId from tr_testitems where ReportNo like '%jsc%' or TaskNo like '%jsc%')
union
SELECT * FROM tr_entrust
where EntrustNo like '%jsc%'

感觉是 Id (select …) or <条件> 这样的结构引起的

Id (select TestId from tr_testitems where ReportNo like '%jsc%' or TaskNo like '%jsc%') or  EntrustNo like '%jsc%'

现在是类似这样的SQL在系统中太多，挨个挨个改工作量太大了，看在TiDb能做什么配置解决该问题不。

另外也没有想明白，Id (select …) or <条件> 这样结构的查询为什么能慢这么多。

[forever]

上面走了hashjion花了5s下面走的indexhashjion花了47ms，id应该是主键，可能因为你多了or条件导致只能全表hash了，你把sql改成关联的试一下呢

[随缘天空 (Ti D Ber Ivw R7o Pj)]

总数据量多大

[TiDBer_ly0m6BIW]

几万条左右

[随缘天空 (Ti D Ber Ivw R7o Pj)]

这么小的数据量体现不了tidb集群的优势。不过执行的耗时确实太慢。两者的表结构一致不，尤其是索引之类的

[TiDBer_ly0m6BIW]

从执行计划上看，在TIKV中扫描表没有耗费多少时间，时间主要耗费在tidb中执行HashJion

[TiDBer_ly0m6BIW]

两个表结构不一致，索引也不同

[residentevil (Ti D Ber Zux S Mt7 W)]

可以建议先对子查询的SQL查看下执行计划，而且看到您发的SQL过滤条件里都是模糊查询&&前后%，这种我也自测过，性能上TIDB和原生MYSQL差异不大

[TiDBer_ly0m6BIW]

已找到问题原因，是由于left outer semi join 算子引起，优化方案在 Null-Aware 问题对 TiDB 优化器的影响(OOM) 有详细介绍