# PostgreSQL order by limit 1的”坑”

> 作者/来源: UCloud 运营管理员
> 发布时间: 2023-01-11T05:20:00.000Z
> 分类: AI专区
> 标签: AI
> 原文链接: http://117.50.162.249:3000/yun/articles/1052

---

# PostgreSQL order by limit 1的”坑”

> 来源: https://www.ucloud.cn/yun/129792.html
> 作者: IT那活儿
> 发布日期: 发布于2023-01-11 13:20

PostgreSQL order by limit 1的”坑”

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_000.png)

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_001.png)

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_002.png)

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

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_003.png)

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_004.png)

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_005.png)

查看统计值

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_006.png)

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

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

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_007.png)

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

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

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

**参考链接：**

https://zhuanlan.zhihu.com/p/45748671

https://dba.stackexchange.com/questions/110636/postgres-poor-performance-on-order-by-id-desc-limit-1/110919

https://stackoverflow.com/questions/6037843/extremely-slow-postgresql-query-with-order-and-limit-clauses

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_008.png)

END

更多精彩干货分享

点击下方名片关注

IT那活儿

![](https://ucloud-blog.cn-bj.ufileos.com/articles/129792/images/129792_009.png)