PostgreSQL order by limit 1的”坑”
PostgreSQL order by limit 1的”坑” 最近在研究一个SQL的时候，发现一个有意思的问题。Sql代码如下： sql代码挺长的，我们直接看它的执行计划，把它的执行计划在https://explain.depesz.com/格式化显示。 通过STATS可以发现，SQL总共执行3.2秒，Limit这个
来源: https://www.ucloud.cn/yun/129792.html 作者: IT那活儿 发布日期: 发布于2023-01-11 13:20
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这种写法是有坑的。如果你发现它有一些慢，建议进行改写。
参考链接：
https://zhuanlan.zhihu.com/p/45748671
END
更多精彩干货分享
点击下方名片关注
IT那活儿
