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

いくつかのクエリの最適化に取り組んでいます。 以下のクエリの場合、 SET STATISTICS IO ON; DECLARE @OrderStartDate DATETIME2 = '27 feb 2016'; DECLARE @OrderEndDate DATETIME2 = '28 feb 2016'; SELECT o.strBxOrderNo , o.sintOrderStatusID , o.sintOrderChannelID , o.sintOrderTypeID , o.sdtmOrdCreated , o.sintMarketID , o.strOrderKey , o.strOfferCode , o.strCurrencyCode , o.decBCShipFullPrice , o.decBCShipFinal , o.decBCShipTax , o.decBCTotalAmount , o.decWrittenTotalAmount , o.decBCWrittenTotalAmount …

15 sql-server  query-performance  sql-server-2014  optimization  index-tuning 

この質問は、とSQL Serverのインデックスのパフォーマンスについてですvarchar(2000)としてINCLUDEの被覆指数インチ 低速で不安定なデータベースアプリケーションのパフォーマンスを改善しようとしています。いくつかのケースでは、データのようなmultple文字列操作を含むクエリで、大VARCHAR列を介してアクセスされるSUBSTRING()、SPACE()とDATALENGTH()。アクセスの簡単な例を次に示します。 update fattable set col3 = SUBSTRING(col3,1,10) + '*' + SUBSTRING(col3,12,DATALENGTH(col3)-12) from fattable where substring(col3,10,1) = 'A' and col2 = 2 スキーマは次のようになります。 CREATE TABLE [dbo].[FatTable]( [id] [bigint] IDENTITY(1,1) NOT NULL, [col1] [nchar](12) NOT NULL, [col2] [int] NOT NULL, [col3] [varchar](2000) NOT NULL, ... 次のインデックスが定義されており、大きなテキスト列にカバーフィールドがあります。 CREATE NONCLUSTERED INDEX [IndexCol2Col3] …

15 sql-server  sql-server-2008  performance  index-tuning 

私はオフィスのさまざまな開発者と、インデックスのコスト、および一意性が有益であるか高価であるか（おそらく両方）について継続的な議論を行ってきました。問題の核心は、競合するリソースです。 バックグラウンド 操作はBツリーのどこに収まるかを暗黙的にチェックし、一意でないインデックスに重複が見つかった場合は、一意化を追加するため、インデックスUniqueを維持するための追加コストはないという説明を以前読んだInsertことがありますキーの終わりですが、それ以外の場合は直接挿入します。この一連のイベントでは、Uniqueインデックスに追加コストはありません。 私の同僚Uniqueは、Bツリー内の新しい位置へのシーク後の2番目の操作として強制されるため、このステートメントに対抗します。したがって、一意でないインデックスよりも維持にコストがかかります。 最悪の場合、テーブルのクラスタリングキーであるID列（本質的に一意）を持つテーブルを見たことがありますが、明示的に非一意であると述べられています。最悪の反対側には、一意性への執着があり、すべてのインデックスは一意として作成されます。インデックスに明示的に一意のリレーションを定義できない場合は、テーブルのPKをインデックスの末尾に追加して、一意性が保証されます。 私は開発チームのコードレビューに頻繁に関与しており、彼らが従うための一般的なガイドラインを提供できる必要があります。はい、すべてのインデックスを評価する必要がありますが、それぞれ数千のテーブルとテーブルに最大20のインデックスを持つ5つのサーバーがある場合、特定のレベルの品質を確保するためにいくつかの簡単なルールを適用できる必要があります。 質問 一意性には、Insert非一意のインデックスを維持するコストと比較して、バックエンドで追加コストがかかりますか？第二に、一意性を確保するためにインデックスの最後にテーブルの主キーを追加することの何が問題になっていますか？ テーブル定義の例 create table #test_index ( id int not null identity(1, 1), dt datetime not null default(current_timestamp), val varchar(100) not null, is_deleted bit not null default(0), primary key nonclustered(id desc), unique clustered(dt desc, id desc) ); create index [nonunique_nonclustered_example] on #test_index (is_deleted) include …

14 sql-server  index-tuning  database-internals  unique-constraint 

2つの列が等しいかどうかに基づいて高速ルックアップが必要です。インデックス付きの計算列を使用しようとしましたが、SQL Serverはそれを使用していないようです。静的に設定されたインデックス付きのビット列を使用するだけで、予想されるインデックスシークが得られます。 このような質問は他にもありますが、インデックスが使用されない理由に焦点を当てたものはありません。 テスト表： CREATE TABLE dbo.Diffs ( Id int NOT NULL IDENTITY (1, 1), DataA int NULL, DataB int NULL, DiffPersisted AS isnull(convert(bit, case when [DataA] is null and [DataB] is not null then 1 when [DataA] <> [DataB] then 1 else 0 end), 0) PERSISTED , DiffComp AS …

14 sql-server  index  index-tuning  computed-column 

テーブルがあります | base_schedule_line_items | CREATE TABLE base_schedule_line_items（ idint（10）unsigned NOT NULL AUTO_INCREMENT、 installmentint（10）unsigned NOT NULL、 on_datedate NOT NULL、 actual_datedate DEFAULT NULL、 payment_typeint（11）NOT NULL、 scheduled_principal_outstandingdecimal（65,0）NOT NULL、 scheduled_principal_duedecimal（65,0） NOT NULL、 scheduled_interest_outstandingdecimal（65,0）NOT NULL、 scheduled_interest_duedecimal（65,0）NOT NULL、 currencyint（11）NOT NULL、 updated_atdatetime NOT NULL DEFAULT '2013-01-06 14：29：16'、 created_atdatetime NOT NULL DEFAULT ' 2013-01-06 14：29：16 '、 loan_base_schedule_idint（10）unsigned NOT NULL、 …

13 mysql  index  index-tuning 

これは奇妙な状況ですが、誰かが答えを持っていることを望んでいます。 いくつかのパフォーマンストラブルシューティング中に、NONCLUSTERED INDEXをテーブルに追加しましたsp_BlitzIndex。翌日にその使用状況を確認したところ、読み取り数が0（スキャン/シークが0、シングルトンルックアップが0）であったため、無効にしました。 すぐに、INDEXを追加したときに最初にチェックして解決しようとしていたのと同じアプリの遅さ（パフォーマンスの問題）の苦情を受け取ります。 さて、理論的には、これはまったく偶然のように聞こえます。インデックスは、証明可能、測定可能、使用されていません。無効にしても、クエリのパフォーマンスが低下することはありません。しかし、それはほとんどだTOO偶然。 質問 したがって、私の質問は、単純に十分なものです。 それはすべての可能で、その利用統計情報（のDMVから/非クラスタ化インデックスは、こと、sp_BlitzIndex）まだされており、NOの使用状況を表示しません助けて影響を受けたテーブルの上に何らかの形でクエリのパフォーマンスを？

13 sql-server  database-design  index-tuning  sql-server-2016  nonclustered-index 

多数の挿入を含むテーブルがあり、フィールド（uploaded_at）の1つをに設定していNULLます。次に、定期タスクがすべてのタプルを選択し、WHERE uploaded_at IS NULLそれらを処理して更新し、uploaded_at現在の日付に設定します。 テーブルにインデックスを付けるにはどうすればよいですか？ 次のような部分インデックスを使用する必要があることを理解しています。 CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL またはそのようなsmth。しかし、常にフィールドにインデックスを付けることが正しい場合、私は少し混乱していますNULL。または、bツリーインデックスを使用することが正しい場合。ハッシュはより良いアイデアのように見えますが、廃止されており、ストリーミングホットスタンバイレプリケーションを介してレプリケートされません。どんなアドバイスも大歓迎です。 私は次のインデックスで少し実験しました： "foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL "foo_part_id" btree (id) WHERE uploaded_at IS NULL クエリプランナーは常にfoo_partインデックスを選択するようです。explain analyseまた、foo_partインデックスの結果が若干良くなります： Index Scan using foo_part on t1 (cost=0.28..297.25 rows=4433 width=16) (actual time=0.025..3.649 rows=4351 loops=1) Index Cond: (uploaded_at …

13 postgresql  index  index-tuning  null 

私の開発者は、ほとんどすべてのテーブルでGUIDをPKとして使用するようにアプリケーションを設定しており、デフォルトでSQL ServerはこれらのPKでクラスター化インデックスを設定しています。 システムは比較的新しく、最大のテーブルは100万行を超えていますが、インデックス作成を検討しており、近い将来必要に応じて迅速にスケーリングできるようにしたいと考えています。 したがって、私の最初の傾向は、クラスター化インデックスを、DateTimeのbigint表現である作成済みフィールドに移動することでした。ただし、CXを一意にできる唯一の方法は、このCXにGUID列を含めることです。ただし、最初に作成されます。 これにより、クラスタリングキーの幅が広がりすぎて、書き込みのパフォーマンスが向上しますか？読み取りも重要ですが、書き込みはおそらくこの時点で大きな懸念事項です。

13 sql-server  index-tuning  clustered-index  uniqueidentifier 

AzureでホストされているSQLデータベースがあります。問題は、サイズが制御不能になっていることです。主キーのクラスター化インデックスで最大99％の断片化が見られます。 他のすべてのインデックスをonline=onオプションで再構築できますが、パフォーマンスには影響しません。PKクラスター化インデックスの1つのサイズが200GBを超えているため、この1つでREBUILD...WITH (ONLINE=ON)はロックが発生します。 すべてのタイムゾーンのユーザーがサイトにアクセスしているため、オフラインでインデックスを再構築できる時間を見つけることができません。 サイトでダウンタイムを発生させずに大きなインデックスを再構築するための最良の戦略は何ですか？ 断片化は99％なので、再編成しても効果がないと思います。問題は、オンラインでもテーブルがロックされることです。主な問題は、インデックスが200GBを超えることです。主キーは整数です。

13 sql-server  index-tuning  azure-sql-database  clustered-index 

SQL Server 2014 Standard Edition 特定の都市を発着する特定の月のフライト数を調べる必要があります。例えば select count(*) from flights where flightTo_AirportCode = 'aaaa' and flightFrom_Airportcode = 'bbbb' and flightdate < '2016-04-01' and flightdate > '2016-02-28' ; テーブルスキーマは次のとおりです。 インデックスmodelAまたはインデックスmodelB（下記）が望ましいかどうかを推定しようとしています（インデックスの作成には何時間もかかり、ディスクスペースでは一度に1つしか存在できないため、跳躍する前に調べます）。 私の経験では、どちらのインデックスでも十分です。私は正しいですか？ create index [modelA] on flights (flightTo_AirportCode, flightFrom_AirportCode, flightDate) create index [modelB] on flights (flightDate, flightTo_AirportCode, flightFrom_AirportCode) （または、より良い、これに取り組むために使用できるバイナリインデックスまたは高度なメカニズムはありますか？） CREATE TABLE [dbo].[flights]( …

11 sql-server  sql-server-2014  index-tuning 

私はいくつかの再発するデッドロックに直面しています。そのうちの1つはキーロックであり、デッドロックの犠牲になるXLOCKヒントを含むSELECTクエリが含まれています。もう1つのステートメントは、最初のクエリのビューの一部であるテーブルの1つへのINSERTです。 見る： create view dbo.viewE as select * from dbo.E where myValue > 13000 クエリを選択： select * from dbo.viewE with (XLOCK) where A > GETUTCDATE() INSERTステートメント： INSERT INTO [dbo].[E] (myValue,A) VALUES (10,GetDate()) 基になるテーブルdbo.Eは、約20列に約300万行を保持しています。それらの一部はntextです。 クエリを取り出し、2つのトランザクションで手動でシミュレーションすると、動作は再現可能です。XLOCKが選択から削除されると、動作が変わります。 デッドロックグラフ： <deadlock-list> <deadlock victim="process222222221"> <process-list> <process id="process222222221" taskpriority="0" logused="0" waitresource="KEY: 5:72057604035644444 (ccdf51accc0c)" waittime="2522" ownerId="27202256401" transactionname="SELECT" lasttranstarted="2015-09-14T16:32:36.160" …

11 sql-server  sql-server-2008-r2  index-tuning  locking  deadlock 

次のシナリオでインデックス付きビューを設定して、2つのクラスター化インデックススキャンなしで次のクエリが実行されるようにしています。このクエリのインデックスビューを作成して使用するときはいつでも、私が付けたインデックスはすべて無視されるようです。 -- +++ THE QUERY THAT I WANT TO IMPROVE PERFORMANCE-WISE +++ SELECT TOP 1 * FROM dbo.TB_test1 t1 INNER JOIN dbo.TB_test2 t2 ON t1.PK_ID1 = t2.FK_ID1 ORDER BY t1.somethingelse1 ,t2.somethingelse2; GO テーブルの設定は次のとおりです。 2つのテーブル 上記のクエリによる内部結合で結合されている 上記のクエリでは、最初の列から、次に2番目のテーブルの列の順になっています。TOP 1のみが選択されています （以下のスクリプトには、問題の再現に役立つ場合に備えて、テストデータを生成する行もいくつかあります） -- +++ TABLE SETUP +++ CREATE TABLE [dbo].[TB_test1] ( [PK_ID1] [INT] IDENTITY(1, …

11 sql-server  sql-server-2008  index  index-tuning  materialized-view 

データベースのテーブルに次のインデックスを作成しました。 CREATE INDEX [idx_index1] on [table1] (col1, col2, col3) サーバーは次の「不足している」インデックスを提案しています： CREATE INDEX [idx_index2] on [table1] (col1, col2) INCLUDE (col3, col4, col5, col6....) 維持する必要のある新しいインデックスを作成するのではなく、提案された列を含めるように既存のインデックス定義を修正するのは私には理にかなっています。col1とcol2を選択するクエリは、index1をindex2と同じくらい効果的に使用できます。私は正しいのですか、それとも何か不足しているのでしょうか？

11 sql-server  sql-server-2008-r2  index  index-tuning 

このクエリに基づいて、総読み取り数が少ない（1または2のように0または0に非常に近い）と、大量または中程度のユーザー更新（このクエリで挿入または削除が見つからなかった）が行数が多い場合、理論的にはインデックスを削除する必要があります。 SELECT DISTINCT OBJECT_NAME(s.[object_id]) AS ObjectName , p.rows TableRows , i.name AS [INDEX NAME] , (user_seeks + user_scans + user_lookups) AS TotalReads , user_updates UserUpdates FROM sys.dm_db_index_usage_stats s INNER JOIN sys.indexes i ON i.[object_id] = s.[object_id] AND i.index_id = s.index_id INNER JOIN sys.partitions p ON p.object_id = i.object_id WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') …

11 sql-server  index  index-tuning  best-practices 

大きなテーブルでI / Oの問題があります。 一般的な統計 このテーブルには次の主な特徴があります。 環境：Azure SQLデータベース（階層はP4プレミアム（500 DTU）） 行：2,135,044,521 使用済みパーティション1,275 クラスター化およびパーティション化されたインデックス 型番 これはテーブルの実装です： CREATE TABLE [data].[DemoUnitData]( [UnitID] [bigint] NOT NULL, [Timestamp] [datetime] NOT NULL, [Value1] [decimal](18, 2) NULL, [Value2] [decimal](18, 2) NULL, [Value3] [decimal](18, 2) NULL, CONSTRAINT [PK_DemoUnitData] PRIMARY KEY CLUSTERED ( [UnitID] ASC, [Timestamp] ASC ) ) GO ALTER …

10 sql-server  query-performance  index-tuning  azure-sql-database