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

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

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

[FutureDB]

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

[forever]

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

[Jellybean (李文杰)]

@额仑小狼

# 挺长的，大概2000~4000多个id

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

[Jasper]

@额仑小狼

69.1ms

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

[tidb狂热爱好者]

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

[kevinsna (Ti D Ber P O Zcnp Ja)]

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

[tidb狂热爱好者]

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

[tidb狂热爱好者]

@额仑小狼

SELECT *
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)

想提升速度其实可以一个用覆盖索引
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依赖磁盘。