为什么SQL查询即使使用ORDERBY子句也会返回未排序的行？

我读到的所有东西都说这不应该发生，但它确实发生了。我的数据库大约15GB大小，几百个表，表可以有几行到几百万行

发生的情况如下：假设我有一个名为

orders

的表，第一列名为

ID

，是该表的主键。还有许多其他列，其中一列名为

policy

。如果我运行以下查询：

SELECT * 
FROM orders 
WHERE policy = 12345 
ORDER BY ID

我希望结果是这样的：

1
2
3
4
5
6

1
2
4
5
3
6

但有时结果会是这样的：

1
2
3
4
5
6

1
2
4
5
3
6

这就好像

3

被移动到了另一个位置。如何/为什么会发生这种情况

实际查询是

SELECT * FROM loc_info WHERE PolInfo_ID=25634 ORDER BY LocInfo_ID

表定义是

CREATE TABLE [dbo].[loc_info]( 
    [LocInfo_ID] [int] IDENTITY(1,1) NOT NULL, 
    [PolInfo_ID] [int] NOT NULL, 
    [name] [varchar](100) NOT NULL, 
    [address1] [varchar](100) NULL, 
    [address2] [varchar](100) NULL, 
    [city] [varchar](100) NULL, 
    [state] [varchar](100) NOT NULL, 
    [zip] [char](10) NULL, 
    [county] [varchar](100) NULL, 
    [country] [varchar](100) NULL, 
    [loc_number] [varchar](20) NULL, 
    [occ_type_id] [int] NULL, 
    [occ_type] [varchar](100) NULL, 
    [flood_zone] [varchar](6) NOT NULL, 
    [coastal_zone] [varchar](20) NOT NULL, 
    [earthquake_zone] [varchar](20) NOT NULL, 
    [earthquake_group] [varchar](20) NULL, 
    [BuildingTIV] [numeric](18, 0) NULL, 
    [MachEquipTIV] [numeric](18, 0) NULL, 
    [StocksSuppliesTIV] [numeric](18, 0) NULL, 
    [OtherTIV] [numeric](18, 0) NULL, 
    [BusinessInterruptTIV] [numeric](18, 0) NULL, 
    [ExtraExpTIV] [numeric](18, 0) NULL, 
    [RentTIV] [numeric](18, 0) NULL, 
    [Property] [numeric](18, 0) NULL, 
    [IsUpload] [bit] NULL, 
    [IsMoved] [bit] NULL, 
 CONSTRAINT [PK_locations] PRIMARY KEY CLUSTERED  
( 
    [LocInfo_ID] ASC
)WITH (PAD_INDEX  = OFF
, STATISTICS_NORECOMPUTE  = OFF
, IGNORE_DUP_KEY = OFF
, ALLOW_ROW_LOCKS  = ON
, ALLOW_PAGE_LOCKS  = ON
, FILLFACTOR = 90) ON [PRIMARY] 
) 

---

这应该是不可能的，假设您订购的列实际上是

LocInfo\u ID

，它确实是一个

INT

，并且在问题发生时确实有一个

ORDER by

子句

如果您能够在这三个条件为真的情况下生成一个有效的复制，那么您的手上就会有一个bug（可能是由腐败引起的）

我怀疑这里还有其他我们不知道的变量。我的猜测是，您正在检查的列不是您正在排序的列，或者它不是您认为的数据类型，或者当您观察这个随机无序的结果时，实际上没有使用的顺序

---

否决这一切您想要的，但这是相当科学和逻辑的-SQL Server不会弄乱您定义的顺序，除非（a）您没有定义它或（b）您没有以生成您期望的顺序的方式定义它。考虑到您坚持认为这是一个非常简单的表和一个非常简单的order by，而且它只是间歇性地发生，我必须同意JNK的观点，并说您在SQL Server中发现错误的可能性确实非常小。

您是否尝试过

按LocInfo\u ID desc排序？只是为了确保正在排序的确实是LocInfo_ID？那三个人会不会不合适呢？似乎有人认为（包括我的）这个查询是嵌入在其他内容中的，或者是作为CTE或TVF的一部分包含的——您还没有上传执行计划。
ID

列是什么数据类型？您在哪里使用结果？订单是视图还是表？请发布实际的表定义和实际的查询。您需要提供一个复制，而不是表设计器的屏幕截图。由于以下几个原因，这个问题非常令人困惑，而且编写得很糟糕，其中一个原因是，所包含的代码示例在给定架构的情况下甚至无法编译。更重要的是，它的模式是在游戏后期提供的。最后，复制的步骤还没有被确定（因此，也没有被呈现）好吧，你所描述的东西错了。或者，您遇到了SQL Server中的错误。无意冒犯，但我的钱在前者身上。@Escobar我同意。现在，你想帮忙解决这个问题吗，还是不行？@escobarceser如果发生这种情况，你真的需要按照MartinSmith说的去做，并检索实际的执行计划again@EscobarCeaser更有可能的是，在一个数据库产品中，

ORDER BY

代码中存在一个非常明显的错误，该数据库产品有数百万次安装，其他人从未注意到，或者在您的情况中有某种特殊情况导致此问题看起来像一个bug，但实际上是查询中其他问题的意外结果？“发生了奇怪的事情。”@escobarceser在SQL server的世界中，奇怪的事情没有发生。不按你所说的来点菜是很奇怪的。我需要一些具体的例子来说明这一点，否则我不相信这是真的。如果这是一个SQL错误，但您不能重新创建它，那么它看起来很奇怪。我们现在要做的就是你说什么时候会发生这种事。