Simple Update ステートメントを実行しています。実行に時間がかかりすぎます。更新とインデックスの詳細は次のとおりです。
エクスポートされた列のデフォルト値は 0 です
UPDATE PAR_ITM SET exported = -1 WHERE exported < 1
索引:
CREATE NONCLUSTERED INDEX [IX_PAR_ITM_Exported_1]
ON [dbo].[PAR_ITM] ([exported] ASC)
WITH (
PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = ON, SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80
) ON [PRIMARY]
したがって、exportedを-1に設定します。ここで、exportedはすでに-1に等しくなります。たぶん、were句をWHERE export = 0に変更すると、ヒットする行が少なくなりますか？
カーディナリティが低い
と呼ばれる問題に苦しんでいますlow cardinality。ウィキペディア
を参照してください。
問題
要するに、すべてのデータベース (私が知っている) は、カーディナリティの低い列でインデックスを使用することを拒否します。
列自体に多くの異なる値がある (列のカーディナリティが高い)場合でも、選択によって多く
の行がヒットする(選択のカーディナリティが低い)と推測される場合、優れたデータベースはインデックスの使用も拒否します。
--insert DB here- がインデックスを使用しないのはなぜですか?
これが問題です。
データベース内のすべての行の 50% 以上 (データベースごとに異なります) が同じ値を持つ場合、インデックスを使用する意味がないため、DB はインデックスを使用しません。
(テーブル自体に対して) 1 回の読み取りを実行できる場合、ほとんどの行に対して 2 回の読み取り (インデックスに対して 1 回読み取り、テーブルに対して 2 回読み取り) を行うのは無意味です。
いずれにせよ、DB はほとんどの行を読み取る必要があるため、先に進んでそれらを読み取ります。
DB が最も遅いアクセス メカニズム (フル テーブル スキャン) を使用してフォールバックしなければならないという事実が、速度低下の原因です。
解決策
列のカーディナリティを増やすか、選択のカーディナリティを増やします。
他の作業では、すべての行の 50% 未満を選択するようにし、SQL サーバーがこれを認識 (または推測) できるようにします。
DB は列のカーディナリティをどのように認識しますか?
優れた DB は、選択/更新/挿入を実行しながら、テーブルと列の統計を保持します。このようにして、十分な情報に基づいた意思決定を行うために必要な情報が得られます。
インデックスの使用を強制すると、クエリが高速化されますか?
いいえ、遅くなります。
SO リンク
MySQL: カーディナリティ/選択度の低い列 = インデックスの作成方法?
選択性の低いカラムのインデックス作成と代替
これに含まれるレコードの数を知るのに役立つ場合があります。
Select Count(*)
FROM PAR_ITM
WHERE exported < 1
基本的に、更新される行数。確かに、100万行でも比較的迅速に実行されます。
他のタイプのクエリはサーバー上でゆっくり実行されますか？
一意性がまったくないように見えるため、ここでは非クラスター化インデックスを使用するべきではないと思いますexported。非クラスター化インデックスの経験則は、95% の一意性です。これは、クエリ オプティマイザーがそれ以外の方法でインデックスを使用しない可能性があるためです。これは、理由もなく速度が低下していることを意味します。
非クラスター化インデックスの説明については、この記事をご覧ください。
http://www.sql-server-performance.com/2007/nonclustered-indexes/
また、別のクエリでブロック状態に陥る可能性もあります。