Home > Article > Backend Development > Bug in use on SQL2k descending index_PHP tutorial
To solve the bug of updating or deleting using comparison conditions on SQL2k descending index, I have tried it in SQL server 2000 enterprise and personal, and it happens every time. (
See my reply for details:
There is indeed no problem in SQl server 7.0. In SQL 2000 (both enterprise and personal versions are available),
The table must have a clustered index, and the order of the indexes must be It is in descending order,
For example, the table created according to the following 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]
After adding some data, AID is distributed between 1-100
INSERT INTO [AType] VALUES(1,'a')
INSERT INTO [AType] VALUES(50,'b')
INSERT INTO [AType] VALUES(100,'c')
Do
select from atype where Aid < 50
go
delete from Atype where AID < 50
go
select from atype where Aid < 50
The last query still has Record the output. :(
by Yihong Gongzi
The report has been sent to the MSSQL development team, and they admitted this error.
Before no new patch comes out, the following suggestions are given:
Do not Use a descending index on a single column, because this does not bring any benefits in terms of performance. It just omits the words Order by field desc. You can see it by using qa's show plan, regardless of whether there is order by or whether it is asc. Or desc, there is no such overhead (on a clustered index).
Descending indexes are generally used for composite indexes, which may be the reason for this bug.
Original text:
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