SQLite使用IN运算符时ID数超26623查询性能骤降问题求助

可能触发的问题原因 #

1. 查询优化器执行计划跳变 #

SQLite的查询优化器会根据IN列表的长度动态调整执行策略，当IN内元素数量达到阈值时，会判定原有的索引匹配策略性价比低于全表扫描/调整连接顺序，恰好你的场景里26624就是这个跳转阈值。
从你的查询结构来看，大概率是执行计划从「先通过IN列表过滤flows表的少量行，再关联其他表做计算」变成了「先做view_requests、虚拟表search_params、flows的全量连接，最后再用IN列表过滤结果」，连接后的中间结果行数直接膨胀上千倍，导致耗时飙升。

2. 自定义虚拟表的开销放大 #

你使用了自定义的search_params虚拟表，虚拟表的查询完全依赖自定义的回调逻辑。如果执行计划跳转后，虚拟表的遍历触发次数从原来的几百次变成几十万甚至上百万次，回调的累计开销会直接把总耗时拉高。你其他用同规模IN列表的查询没出问题，大概率是那些查询没有涉及自定义虚拟表的高频回调。

3. IN列表匹配逻辑切换 #

SQLite处理IN列表时，短列表默认用有序数组二分查找，超过阈值后会切换为哈希表匹配，3.36.0版本在特定编译参数下这个切换逻辑存在边缘case的性能bug，会导致哈希表构建和匹配的耗时异常升高。

排查和解决建议 #

• 先执行EXPLAIN QUERY PLAN分别跑26623个ID和26624个ID的查询，对比两者的执行计划差异，重点看表的扫描顺序、是否命中索引、SCAN和SEARCH的区别。
• 放弃动态拼接IN列表的方案，把需要匹配的ID批量插入临时表，再把查询改成和临时表JOIN过滤flows.id，不管ID数量多少，优化器都能生成稳定的执行计划，不会出现跳变。
• 确认flows表的id字段是否有索引，如果没有索引先加上索引，可以大幅提升IN匹配的效率。
• 如果确认是执行计划顺序问题，可以用CROSS JOIN强制表的连接顺序，避免优化器乱序。

内容的提问来源于stack exchange，提问作者Prinzhorn