在SQL2k降序索引上使用中bug
作者：袖梨
2022-07-02
解决SQL2k降序索引上使用对比条件更新或删除的bug我在SQL server 2000 enterprise 和 personal 都试过了， 每次都这样。：(
详细情况看我的回贴：
SQl server 7.0 中的确没有问题， sql 2000 中（enterprise 和 personal版本都可以），
表要有聚簇索引，并且索引的顺序是降序，
例如 按下列DDL sql 建立的表
CREATE TABLE [AType] (
[AID] [int] NOT NULL ,
[name] [varchar(20)] NOT NULL ,
CONSTRAINT [PK_DateType] PRIMARY KEY CLUSTERED
([AID] DESC) ON [PRIMARY] ,
) ON [PRIMARY]
添一些数据后， AID 分别分布在1-100之间
INSERT INTO [AType] VALUES(1,'a')
INSERT INTO [AType] VALUES(50,'b')
INSERT INTO [AType] VALUES(100,'c')
做
select from atype where Aid < 50
go
delete from Atype where AID < 50
go
select from atype where Aid < 50
最后一句查询仍然有记录输出. :(
by 怡红公子
报告已经发送给MSSQL开发小组，他们承认这一错误。
在没有新的补丁出来之前，给出以下建议：
不要在单列上使用降序索引，因为这并没有在性能上带来好处，仅仅是省略了Order by field desc几个字而已，用qa的show plan看一下就知道了，不管有没有order by或者不管是asc还是desc，都没有这项开销的（在聚簇索引上）。
降序索引一般是用于复合索引的，这可能是这个bug出现的原因。
原文：
Note that there is no need to create a descending index on a single column because SQL Server can traverse
an ascending index backwards when appropriate. Descending is normally used only in composite indexes.
This is probably why the bug surfaces here
详细情况看我的回贴：
SQl server 7.0 中的确没有问题， sql 2000 中（enterprise 和 personal版本都可以），
表要有聚簇索引，并且索引的顺序是降序，
例如 按下列DDL sql 建立的表
CREATE TABLE [AType] (
[AID] [int] NOT NULL ,
[name] [varchar(20)] NOT NULL ,
CONSTRAINT [PK_DateType] PRIMARY KEY CLUSTERED
([AID] DESC) ON [PRIMARY] ,
) ON [PRIMARY]
添一些数据后， AID 分别分布在1-100之间
INSERT INTO [AType] VALUES(1,'a')
INSERT INTO [AType] VALUES(50,'b')
INSERT INTO [AType] VALUES(100,'c')
做
select from atype where Aid < 50
go
delete from Atype where AID < 50
go
select from atype where Aid < 50
最后一句查询仍然有记录输出. :(
by 怡红公子
报告已经发送给MSSQL开发小组，他们承认这一错误。
在没有新的补丁出来之前，给出以下建议：
不要在单列上使用降序索引，因为这并没有在性能上带来好处，仅仅是省略了Order by field desc几个字而已，用qa的show plan看一下就知道了，不管有没有order by或者不管是asc还是desc，都没有这项开销的（在聚簇索引上）。
降序索引一般是用于复合索引的，这可能是这个bug出现的原因。
原文：
Note that there is no need to create a descending index on a single column because SQL Server can traverse
an ascending index backwards when appropriate. Descending is normally used only in composite indexes.
This is probably why the bug surfaces here
