タグ付けされた質問 「filtered-index」

MySQLのテーブルの特定の範囲またはサブセットをフィルターするインデックスを作成する方法は？知る限りでは、直接作成することはできませんが、この機能をシミュレートすることは可能だと思います。 例：次のNAME行だけの列のインデックスを作成したいSTATUS = 'ACTIVE' この機能は、SQL Serverではフィルター選択されたインデックス、Postgres では部分インデックスと呼ばれます。

24 mysql  index  filtered-index 

次のようなテーブル定義があると仮定します。 CREATE TABLE MyTab ( ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY ,GroupByColumn NVARCHAR(10) NOT NULL ,WhereColumn DATETIME NULL ) そして、次のようなフィルター処理された非クラスター化インデックス： CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab (GroupByColumn) WHERE (WhereColumn IS NULL) このインデックスがこのクエリで「カバー」されていない理由： SELECT GroupByColumn ,COUNT(*) FROM MyTab WHERE WhereColumn IS NULL GROUP BY GroupByColumn 私はこの実行計画を取得しています： KeyLookupは、WhereColumn IS NULL述語用です。 計画は次のとおりです。https：//www.brentozar.com/pastetheplan/？id …

18 sql-server  query-performance  index-tuning  filtered-index 

私の前の質問で、テーブルに新しい計算列を追加するときにロックエスカレーションを無効にすることは良い考えですか？、計算列を作成しています： ALTER TABLE dbo.tblBGiftVoucherItem ADD isUsGift AS CAST ( ISNULL( CASE WHEN sintMarketID = 2 AND strType = 'CARD' AND strTier1 LIKE 'GG%' THEN 1 ELSE 0 END , 0) AS BIT ) PERSISTED; 計算列はPERSISTEDであり、compute_column_definition（Transact-SQL）によると： 執着 データベースエンジンがテーブルに計算値を物理的に格納し、計算列が依存する他の列が更新されたときに値を更新することを指定します。計算列にPERSISTEDのマークを付けると、確定的ではあるが正確ではない計算列にインデックスを作成できます。詳細については、計算列のインデックスを参照してください。パーティションテーブルのパーティション列として使用される計算列には、明示的にPERSISTEDのマークを付ける必要があります。PERSISTEDが指定されている場合、compute_column_expressionは確定的でなければなりません。 しかし、列にインデックスを作成しようとすると、次のエラーが表示されます。 CREATE INDEX FIX_tblBGiftVoucherItem_incl ON dbo.tblBGiftVoucherItem (strItemNo) INCLUDE (strTier3) WHERE isUsGift = 1; …

17 sql-server  index  sql-server-2014  computed-column  filtered-index 

NULL不可の値に対してフィルター処理された一意のインデックスを持つテーブルがあります。クエリプランでは、distinctの使用があります。これには理由がありますか？ USE tempdb CREATE TABLE T1( Id INT NOT NULL IDENTITY PRIMARY KEY ,F1 INT , F2 INT ) go CREATE UNIQUE NONCLUSTERED INDEX UK_T1 ON T1 (F1,F2) WHERE F1 IS NOT NULL AND F2 IS NOT NULL GO INSERT INTO T1(f1,F2) VALUES(1,1),(1,2),(2,1) SELECT DISTINCT F1,F2 FROM T1 WHERE F1 …

15 sql-server  optimization  filtered-index 

次のSQLクエリがあります。 SELECT Event.ID, Event.IATA, Device.Name, EventType.Description, Event.Data1, Event.Data2 Event.PLCTimeStamp, Event.EventTypeID FROM Event INNER JOIN EventType ON EventType.ID = Event.EventTypeID INNER JOIN Device ON Device.ID = Event.DeviceID WHERE Event.EventTypeID IN (3, 30, 40, 41, 42, 46, 49, 50) AND Event.PLCTimeStamp BETWEEN '2011-01-28' AND '2011-01-29' AND Event.IATA LIKE '%0005836217%' ORDER BY Event.ID; …

14 sql-server-2008-r2  query-performance  filtered-index 

私はこの表を持っています： CREATE TABLE Table01 (column01 nvarchar(100)); そして、この条件LEN（column01）> = 5でcolumn01に一意のインデックスを作成したい 私は試した： CREATE UNIQUE INDEX UIX_01 ON Table01(column01) WHERE LEN(column01) >= 5; 私が得た： テーブル 'Table01'のフィルター選択されたインデックス 'UIX_01'のWHERE句が正しくありません。 そして： ALTER TABLE Table01 ADD column01_length AS (LEN(column01)); CREATE UNIQUE INDEX UIX_01 ON Table01(column01) WHERE column01_length >= 5; 生産物： フィルター式の列「column01_length」が計算列であるため、フィルター索引「UIX_01」を表「Table01」に作成できません。この列が含まれないようにフィルター式を書き直してください。

12 sql-server  sql-server-2008-r2  filtered-index 

現在、tb_tranfersという名前のテーブルを使用しています。このテーブルには4,000万行あり、サイズは最大26 GB（11 GBのデータ、15 GBのインデックス）です。 行の10〜15％が一時削除された行です（DeletedDateはnullではありません）。アプリケーションはDeletedDateがnullである行のみを使用します。このテーブルへのすべてのクエリには、その効果に対する句が含まれます。 このテーブルには15のインデックスがあります。欠落しているインデックスDMVには、削除された日付を含む列としてインデックスを作成するための提案が含まれています。 WHERE DeleteDdate IS NULL11個の整理されていないインデックスすべてにフィルター処理されたインデックスを使用することは役に立ちますか？または、DeletedDate列をインクルード列として持つ方が良いでしょうか？

11 sql-server  index  filtered-index 

以下のフィルターされたインデックスを作成しましたが、2つのクエリをさらに実行すると、このインデックスは、where句ではなく、JOINにEND_DTTMがある最初の例のシークにのみ使用されます（クエリの唯一の違いです）。 。なぜこれが起こるのか誰かが説明できますか？ インデックスの作成 CREATE NONCLUSTERED INDEX [ix_PATIENT_LIST_BESPOKE_LIST_ID_includes] ON [dbo].[PATIENT_LIST_BESPOKE] ( [LIST_ID] ASC, [END_DTTM] ASC ) WHERE ([END_DTTM] IS NULL) クエリ DECLARE @LIST_ID INT = 3655 --This one seeks on the index SELECT PATIENT_LISTS.LIST_ID FROM DBO.PATIENT_LISTS LEFT JOIN DBO.PATIENT_LIST_BESPOKE ON PATIENT_LISTS.LIST_ID = PATIENT_LIST_BESPOKE.LIST_ID AND PATIENT_LIST_BESPOKE.END_DTTM IS NULL WHERE PATIENT_LISTS.LIST_ID = @LIST_ID …

10 sql-server  t-sql  index  query-performance  filtered-index 

私たちのプロジェクトは、非常に大規模で非常に複雑なデータベースを実行しています。そのため、約1か月前に、null値を含むインデックス付き列で使用される領域が大きくなりすぎていることに気付きました。これに対する応答として、1％を超えるnull値を含むすべての単一列インデックスを動的に検索し、値がNOT NULLであるという条件でフィルター処理されたインデックスとしてそれらのインデックスを削除して再作成するスクリプトとして書きました。これにより、データベース全体で数百のインデックスが削除および再作成され、通常、DB全体で使用されるスペースのほぼ15％が解放されます。 今私はこれについて2つの質問があります： A）この方法でフィルター処理されたインデックスを使用することの欠点は何ですか？パフォーマンスが向上するだけだと思いますが、パフォーマンス上のリスクはありますか？ B）インデックスを削除して再作成すると、「インデックスXYZは削除できないため、削除できません」というエラーが発生しました。後でチェックすると、すべてが期待どおりに実行されました。これはどうして起こりますか？ 助けてくれてありがとう！ 編集： @Thomas Kejserへの返信 こんにちは、ありがとうございます。しかし、これは災害でした。当時、私たちは次のようないくつかのことを理解していませんでした： SQLOSはクエリ中に、テーブル列の結合にNULL値を使用できないと判断する前に、インデックスプランを作成します。つまり、クエリで使用されるすべてのフィルター処理されたインデックスのインデックスをフィッティングするWHERE句フィルターが本当に必要です。そうしないと、インデックスはまったく使用されません。 インデックスを削除して作成し、その後統計を冗長に更新するだけでは、更新された計画を作成するには不十分である可能性があります。場合によっては、SQL Serverが計画の再評価を余儀なくされるほど高いワークロードのみが表示されることがあります。 常識とロジックだけで判断するのが難しい実行プランナーの機能には、いくつかの珍しいものがあります。数千のコードビハインドで生成されたさまざまなクエリのバリエーションでさえ、一見役に立たないように見えるインデックスは、重要なクエリで使用される統計やクエリプランに役立ちます。 最終的に、これらの変更は元に戻されました。したがって、フィルター選択されたインデックスは強力なツールですが、これらの列からフェッチされるデータを正確に理解する必要があります。スペースの問題は別として、通常のインデックスは適用がかなり簡単ですが、フィルター選択されたインデックスは非常にカスタマイズされたソリューションを表します。これらは通常のインデックスの代わりではなく、必要な特別な状況での拡張です。

10 sql-server  index  filtered-index 

フィルターされたインデックス内にORを配置する場合の回避策はありますか？ create index FIDX_tblbOrders_sdtmOrdCreated_INCL on dbo.tblBOrder(sdtmOrdCreated) INCLUDE (sintMarketID, strCurrencyCode, sintOrderStatusID ) WHERE ((sintMarketId=1) AND ( (sintOrderStatusId < 9) OR (sintOrderStatusId > 14))) 上記のインデックスを作成しようとしています。sintOrderStatusIdがIN（9-14）である状況には興味がないためです。 もちろん、ビューやインデックス付きビューを作成することはできますが、それを避けようとしていました。 情報を追加するだけ：sintOrderStatusIdはsmallint NOT NULLであり、可能な値の範囲は1〜30です。9〜14は避けてください。したがって、フィルターされたインデックスです。

8 sql-server  sql-server-2014  filtered-index