数据库实战踩坑指南2：Order by也有坑

分手后的思念是犯贱 2023-10-03 10:26 22阅读 0赞

在SQL查询中，Order by子句无疑是最常用的关键字，毕竟现实世界里几乎很少会存在不带排序的业务行为。

然而，细节是魔鬼，即使是这么常用的关键字，一样是有坑的哦！下面就是一则关于order by的避坑指南。

假设在Microsoft SQL Server（或Azure SQL Database）中，有如下数据：

![756eb377a4afac5d5412c53e1dc522ee.png][]

开发者企图进行一个“翻页”查询，依据T-SQL语法编写代码类似于:

Select * from 成绩表 Order By 成绩 ASC OFFSET 0 ROWS FETCH NEXT 3 ROWS ONLY 
    Select * from 成绩表 Order By 成绩 ASC OFFSET 3 ROWS FETCH NEXT 3 ROWS ONLY

上述两条查询进行了常见的“翻页”查询操作，出于简化演示目的，每页显示条数为3条，分别查询第一页和第二页数据。然后，执行结果就掉到坑里了！

图中左侧是期待的第一页和第二页的示意。右侧是一种**可能**的查询结果的示例，其效果是，Id 16的项出现在了两页中，但17号数据完全没有出现。

![8e19abfe9aea6e0922b428a45c23cdb4.png][]

注意，该数据效果仅为演示，因其是**偶发**形态，**不**确保重现成功。

为什么会有这种bug呢？其实这不是bug，而是feature。

根据文档，如果需要得到“稳定可靠”的翻页查询结果，Order by子句必须要做到“确保唯一”。而我们的 *OrderBy 成绩 ASC* 并不具备唯一性。

![4bfb62db2c50b2ab26cbb7a19116fe2b.png][]

所以，正确的Order by子句可以是这样的（其中ASC可以从略）：

......  OrderBy 成绩 ASC, Id ASC ......

这个知识点其实一直就在文档里，只是孤立阅读文档的时候并不会意识到，操作不正确的后果是什么样的——毕竟文档没告诉你“不稳定可靠”会发生啥具体后果。而最麻烦的是，前面提到了，该查询效果是偶发的，在没有遇上问题之前，开发者们并不会发现这么写有什么不妥。

本文展示的是T-SQL的情况，实际上在其它的数据库中也都有类似的效果，语法各有差异，原理相同，不一一展示了。

参考文档：

[ORDER BY Clause (Transact-SQL) - SQL Server][ORDER BY Clause _Transact-SQL_ - SQL Server]

[756eb377a4afac5d5412c53e1dc522ee.png]: https://img-blog.csdnimg.cn/img_convert/756eb377a4afac5d5412c53e1dc522ee.png
[8e19abfe9aea6e0922b428a45c23cdb4.png]: https://img-blog.csdnimg.cn/img_convert/8e19abfe9aea6e0922b428a45c23cdb4.png
[4bfb62db2c50b2ab26cbb7a19116fe2b.png]: https://img-blog.csdnimg.cn/img_convert/4bfb62db2c50b2ab26cbb7a19116fe2b.png
[ORDER BY Clause _Transact-SQL_ - SQL Server]: https://docs.microsoft.com/en-us/sql/t-sql/queries/select-order-by-clause-transact-sql?view=sql-server-ver15