SQL2k の降順インデックスで使用されているバグ_PHP チュートリアル

SQL2k 降順インデックスの比較条件を使用して更新または削除するバグを解決するために、SQL Server 2000 Enterprise および Personal で試しましたが、毎回この問題が発生します。 (
詳細については、私の返信を参照してください:
SQL サーバー 7.0 では確かに問題はありません。SQL 2000 (エンタープライズ バージョンとパーソナル バージョンの両方が利用可能) では、
テーブルにはクラスター化インデックスが必要で、インデックスの順序は降順です。順序、
例えば、以下の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')
Aid AID select from atype where Aid 最後のクエリにはまだレコード出力があります :(
Yihong Gongzi による
レポートは MSSQL 開発チームに送信され、彼らはこのエラーを認めました。
新しいパッチが公開される前に、次の提案があります:
単一の列に降順インデックスを使用しないでください。これは、フィールドの説明による順序という単語を省略するだけです。 order by があるかどうか、asc. または desc であるかどうかに関係なく、(クラスター化インデックスでは) このようなオーバーヘッドはありません。
複合インデックスには通常、降順インデックスが使用されます。これがこのバグの原因である可能性があります。 SQL Server は必要に応じて昇順インデックスを逆方向に走査できるため、単一の列に降順インデックスを作成する必要はありません
これがおそらくここでバグが表面化する理由です

。


http://www.bkjia.com/PHPjc/631191.html

www.bkjia.com

tru​​e

http://www.bkjia.com/PHPjc/631191.html技術記事 SQL2k 降順インデックスの比較条件を使用して更新または削除するバグを解決するために、SQL Server 2000 Enterprise および Personal で試しましたが、毎回この問題が発生します。 (詳細については私の返信をご覧ください:...