【 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中的执行计划
针对这样的问题有什么优化方式吗？
MySQL里的用了执行计划， tidb还是全表扫描。 这样的情况下，检查下索引情况吧，是不是tidb上没有对应索引呀。
应该不是索引问题，把上面的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 <条件> 这样结构的查询为什么能慢这么多。
上面走了hashjion花了5s下面走的indexhashjion花了47ms，id应该是主键，可能因为你多了or条件导致只能全表hash了，你把sql改成关联的试一下呢
总数据量多大
几万条左右
这么小的数据量体现不了tidb集群的优势。不过执行的耗时确实太慢。两者的表结构一致不，尤其是索引之类的
从执行计划上看，在TIKV中扫描表没有耗费多少时间，时间主要耗费在tidb中执行HashJion
两个表结构不一致，索引也不同
可以建议先对子查询的SQL查看下执行计划，而且看到您发的SQL过滤条件里都是模糊查询&&前后%，这种我也自测过，性能上TIDB和原生MYSQL差异不大