SQLite聚合查询GROUP BY后ORDER BY DESC生成TEMP B-TREE性能问题咨询

这确实是SQLite 3.26.0版本在处理聚合+降序排序时的已知优化限制，不是你的操作或预期有问题——你的判断（索引支持双向遍历，升序降序应该性能一致）是合理的，只是旧版本的优化器还没覆盖这个场景。

为什么升序无需临时B树？ #

对于SELECT x,max(y) FROM t1 GROUP BY x ORDER BY x;：

• 索引ix1(x,y)是按x ASC, y ASC排列的，SQLite可以直接顺序遍历索引，按x的自然顺序分组计算max(y)（遍历到相同x的行时，最后一个y就是最大值，因为y也是升序的）。
• 分组完成后，结果本身就是x升序的，刚好匹配ORDER BY x的要求，所以不需要额外排序，直接输出即可，全程只需要索引扫描。

为什么降序需要临时B树？ #

对于SELECT x,max(y) FROM t1 GROUP BY x ORDER BY x DESC;：

• 虽然索引支持反向遍历（从大到小读x），但SQLite 3.26.0的优化器还无法在聚合（GROUP BY）过程中，同时利用反向索引遍历直接生成x降序的分组结果。
• 它的处理逻辑是：先按索引升序完成聚合，得到x升序的分组结果，然后为了满足ORDER BY x DESC的要求，不得不把这些分组数据写入TEMP B-TREE进行排序，最终输出降序结果——这就是你看到的额外临时树创建步骤。

后续版本的改善 #

这个限制在SQLite的后续版本（比如3.30.0及以后）中已经被优化：优化器可以识别到反向索引遍历既能满足分组的顺序要求，又能匹配降序排序的需求，直接反向遍历索引完成聚合，同时输出x降序的结果，不再需要临时B树。如果条件允许，升级SQLite版本就能解决这个性能问题。

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