IN值比较多的情况下,查询比较慢,如何优化?

从执行计划来看已经比较好了,会不会执行前的调度和准备时间占用了大部分时间,这个估计要到对应的监控界面查看了

看下是不是网络返回数据慢

添加一个这三个deleted,id,group_id 列的索引试一下呢,不让他走BitmapAnd

通常in的逻辑是等价于 or 逻辑,不建议一次性放太多个。单机数据库数据可能都在cache里,而tidb作为分布式数据库数据基本都分布在不同节点的磁盘上,而且访问网络链路会更长,网络传输时间也会有差异。具体的执行需要的时间可看详细计划,楼主贴一下tidb在explain analyze 之后的的执行计划。

这个 执行计划中的 69.1ms 就是真实的执行时间, in 值太多可能会造成解析编译时间比较长,建议你 dashboard 里面慢查询页面看看能不能找到这条sql ,下面有个 time 面板可以看到具体时间花费在哪了

1 个赞

你写的这个sql 就是返回60ms,你说的1.3s可能同时在有其他任务在跑 比如归档

可以考虑尝试调整下 tidb_distsql_scan_concurrency参数的值 ,以提高并行处理的能力

磁盘性能差估计改什么都没用的 你看看现在是不是跑的快了很多。

想提升速度其实可以一个用覆盖索引
SELECT content
FROM t_asset a
WHERE a.id IN

挺长的,大概2000~4000多个id

  (5407245, 4789312, 4790104, 4790090, 146919, 146991, 146800, 4790169, 4790758, 4789391, 4788565, 4788849, 4790606,
   4788529, 5352812, 4790050, 4788988, 5411650, 4790510, 146828, 190720, 146850, 4789374, 4791460, 4790672, 4790092……)

AND a.group_id IN
(22099, 56611, 4825, 3570, 3571, 4984, 10591, 56429, 22145, 3631, 3572, 58375, 539908, 58819, 3544, 3574, 310, 3632, 5081, 4222, 5001, 3630, 3633, 3634, 3635)
create index idx_all (content,id,group_id ) on table t_asset ;
1.这样的话索引就全部覆盖所有的查询不用去回表了。
2。 别用deleted 这种标签列 这种列不是0,就是1,散化不严重。无法用索引加速。 大部分都是0.这个时候无法走索引的。你改成is_not_deleted=1 你查delete掉的数据非常快,想查没有delete的数据就得走所有列。所以真的删除就删除。如果一定要保留另建表备份删除的数据。
3.如果用覆盖索引还慢,就考虑磁盘io吧。磁盘太差了。tidb依赖磁盘。

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。