PostgreSQL order by limit 1的”坑”

最近在研究一个SQL的时候，发现一个有意思的问题。Sql代码如下：

sql代码挺长的，我们直接看它的执行计划，把它的执行计划在https://explain.depesz.com/格式化显示。

通过STATS可以发现，SQL总共执行3.2秒，Limit这个操作占用了近1.1秒的时间。这里首先我们对数据进行全部排序，排序完后选择整个记录的第一行。按道理来说慢应该在排序这个地方，而不应该在limit 1这里。

为了研究这个问题，搜索了一下，发现stackoverflow中有人提过这类问题。

我按照这个思路，把这个SQL进行了改写，使用了row_number() OVER()的方式。改写后代码如下：

经过改写后的执行计划如下：

查看统计值

几乎没有特别高消耗。执行时间从3.2秒下降到1.4秒。

当然此类问题还有很多，都是limit 1引起的。我在stackexchange上也发现了这样的一个案例。

我们观察它改写之前和改写之后的SQL，整个改写就是把它变成了子查询就正常了。这是因为前面的SQL没有使用上索引，改成子查询后就使用上了索引。

知乎上也有作者遇到这个问题，并按照这个方式解决了。https://zhuanlan.zhihu.com/p/45748671

所以说order by Limit n这种写法是有坑的。如果你发现它有一些慢，建议进行改写。

END

更多精彩干货分享

点击下方名片关注

IT那活儿