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

Question

我读过的所有内容都说这不应该发生,但它会发生.我的数据库大小约为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

好像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] 
) 

Answer 1

这是不可能的,假设您订购的列实际上LocInfo_ID是真的INT,并且ORDER BY在问题发生时您确实有一个子句.

如果您可以在这三个条件成立的情况下生成有效的repro,那么您手上就会有一个错误(可能是由于腐败造成的).

我怀疑这里还有其他变量我们不知道.我的猜测是,你检查列是不是你下令由一个,或者不是你认为它是,或当你观察这个随机无序的结果,没有实际作为一个顺序的数据类型用过的.

反对票这一切你想要的,但是这是非常科学和逻辑- SQL Server不会弄乱的ORDER BY,你已经定义,除非(a)您没有把它定义或(b)在你没有把它定义一种产生您期望的订单的方式.既然你坚持认为这是一个非常简单的表格和一个非常简单的顺序通过,并且它只能间断性地发生,我有JNK同意,说你已经发现了在SQL Server中的错误的可能性非常小确实.