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

現在、完全に機能する既存のデータベースとアプリケーションがあります。この時点でアーキテクチャを変更することはできません。今日、データベース内の各テーブルには、「IsDeleted」NOT NULL BITフィールドがあり、デフォルトは「0」です。アプリケーションがデータを「削除」すると、IsDeletedフラグが1に更新されます。 私が理解できないのは、各テーブルのインデックスの構成方法です。現在、すべてのquery / join / etcは常にIsDeletedチェックを実装しています。開発者が従わなければならない標準です。そうは言っても、各テーブルのクラスター化プライマリキーインデックスをすべて変更して、プライマリキーとIsDeleted BITフィールドを含める必要があるかどうかを判断しようとしています。また、すべてのquery / join / etcから。IsDeletedチェックを実装する必要がありますが、すべての単一のインデックス（非クラスター化）がIsDeletedフィールドをインデックスの最初のフィールドとして含むべきであるという適切な仮定ですか？ もう1つの質問は、フィルター選択されたインデックスに関するものです。「WHERE IsDeleted = 0」などのインデックスにフィルターを適用して、インデックスのサイズを小さくできることを理解しています。ただし、すべての結合/クエリはIsDeletedチェックを実装する必要があるため、（結合/クエリでIsDeleted列が使用されるため）フィルター選択されたインデックスが使用されないようにしますか？ 私は、IsDeletedアプローチを変更する能力がないことを忘れないでください。

16 sql-server  sql-server-2012  index 

私はインデックスが遅くなると人々が言うのを常に見ますupdate、deleteそしてinsert。これは、まるで絶対的なものであるかのように、ブランケットステートメントとして使用されます。 データベースを調整してパフォーマンスを向上させている間、私はこの規則に論理的に矛盾していると思われるこのような状況に出くわします。 SQL Serverでは、他のほとんどのDBMSを使用すると考えられますが、インデックスは指定した特定の列に基づいて作成されます。挿入と削除は常に行全体に影響を与えるため、インデックスに影響を与えることはありませんが、更新はもう少しユニークに見えます。特定の列にのみ影響します。 インデックスに含まれていない列があり、それらを更新する場合、そのテーブル内の他の列にインデックスがあるために、それらは遅くなりますか？ たとえば、私のUserテーブルには、1つまたは2つのインデックス、Identity / Auto Incrementカラムであるプライマリキー、および場合によっては外部キーカラム上の別のインデックスがあります。 電話番号や住所など、インデックスのない列を直接更新すると、どちらの状況でもこのテーブルのインデックスが他の列にあるため、この更新は遅くなりますか？更新している列はインデックスにないため、論理的には、インデックスを更新しないでください。どちらかと言えば、WHERE句でインデックスを使用すると、速度が向上すると思います。

16 sql-server  index  query-performance  update 

7月にサーバーが最後に再起動されて以来蓄積されているDMV統計によると、数百の未使用のインデックスを持つ非常に大きなデータベースがあります。DBAの1人が次の警告文を作成しましたが、私には意味がありません。 インデックスを削除する前に、クエリオプティマイザーがこのインデックスの存在を必要とする可能性があるため、一意性制約が適用されていないことを確認する必要があります。 インデックスが作成されるたびに、そのインデックスに関連する統計もSQL Serverに作成されます。クエリはインデックスを使用していない可能性がありますが、統計を使用している可能性があります。そのため、インデックスを削除した後、特定のクエリパフォーマンスが非常に悪くなるという状況が発生する場合があります。SQL Serverは、統計の使用統計を保持しません。データベースで「統計の自動作成」機能を有効にしていますが、クエリオプティマイザーが不足している統計を作成する前に、すべてのパラメーターを内部で満たす必要があるかわかりません。 ＃1に関しては、SQL Serverは実際にインデックスのシークを行って、挿入/更新が行われる前に一意性を判断するため、インデックスは使用されていないようには見えません。 ＃2に関して、これは本当に可能ですか？ ちなみに、インデックスを使用しないという場合、シークもスキャンもありません。

16 sql-server  index 

SQLサーバーはSAN上にあります。多数のOLTPデータベースが含まれており、一部には1m以上のレコードを含むいくつかのテーブルがあります。 私たちは、実行されているオラHallengrenの索引メンテナンススクリプトを毎週、そしてそれは、数時間ごとに実行されます。断片化のしきい値に基づいて、スクリプトはインデックスを再編成または再インデックス化します。インデックスの再作成中にログファイルが膨大になり、ログ配布中に帯域幅が過剰に消費されることが確認されています。 次に、ブレント・オザールからの記事があります。彼はSQLインデックスについて心配するのをやめると言っています。 ハードドライブは、同時にドライブリクエストを行っている他のサーバーと共有されるため、ドライブは常にデータを取得するためにあらゆる場所でジャンプします。インデックスの最適化は、無意味な忙しい作業です。 この質問をググリングすると、さまざまな意見につながりますが、ほとんどが短すぎるか弱すぎると思われる議論でサポートされています。暫定的な計画では、メンテナンススクリプトの断片化のしきい値を調整して、インデックスの再作成よりもはるかに頻繁に再編成するようにします。 最終的な判定は何ですか？毎週のメンテナンスジョブの実行に伴う負担を考慮して、SANでSQLインデックスを最適化することは価値がありますか？

16 sql-server  sql-server-2008-r2  index  database-recommendation  san 

次の表とインデックスの定義があります。 CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); munkalap_idのインデックスが次のクエリで使用されないのはなぜですか？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …

16 postgresql  performance  index  join  primary-key 

環境 この質問は、SQLデータベースシステムとNoSQLデータベースシステムの両方でのインデックスの低レベルの実装の詳細に関するものです。質問はこれらの実装の単一ノード内に保存されたキーに特に関係するため、インデックスの実際の構造（B +ツリー、ハッシュ、SSTableなど）は無関係です。 バックグラウンド SQL（MySQLなど）およびNoSQL（CouchDB、MongoDBなど）データベースでは、データの列またはJSONドキュメントフィールドにインデックスを作成するときに、実際にデータベースに実行させるのは、本質的にすべてのソート済みリストを作成することですこれらの値と、その値に関連するレコードが存在するメインデータファイルへのファイルオフセット。 （簡単にするために、特定の実装のその他の難解な詳細を手で振り払うかもしれません） シンプルなクラシックSQLの例 インデックスを作成する単純な32ビットint主キーを持つ標準SQLテーブルを考えます。データファイルへの64ビットオフセットに関連付けられ、関連付けられた整数キーのディスク上のインデックスが作成されます。レコードは存続します。例： id | offset -------------- 1 | 1375 2 | 1413 3 | 1786 インデックス内のキーのディスク上の表現は、次のようになります。 [4-bytes][8-bytes] --> 12 bytes for each indexed value ファイルシステムとデータベースシステムでのディスクI / Oの最適化に関する標準的な経験則に固執して、ディスク上の4KBブロックにキーを保存するとします。 4096 bytes / 12 bytes per key = 341 keys per block インデックスの全体構造（B +ツリー、ハッシュ、ソート済みリストなど）を無視して、341キーのブロックを一度に読み書きし、必要に応じてディスクに戻します。 クエリの例 前のセクションの情報を使用して、「id = …

16 mongodb  index  nosql  couchdb 

別のファイルグループとドライブにインデックスを保存すると、ドライブがインデックスとインデックスが参照するデータとの間を行き来する必要がないため、データベースのパフォーマンスが向上すると聞きました。また、これは神話だと聞いたことがあります。 非クラスター化インデックスを別のファイルグループとドライブに保存することをお勧めします。どのようなperfmon / profilerの証拠がその結論に到達するのに私を導くでしょうか？ハードウェアは決定に役割を果たしますか（RAID / SANが単一のドライブで使用されるかどうか）？

16 sql-server  index 

ですから、私のdb設計を完​​全に制御することはできません。そのため、このシナリオの目的のために現在のシステムの多くの側面を変更することはできません。 デザインの側面をどのように再考すべきかについてのコメントはおそらく正しいが、役に立たない:) 私は非常に大きなテーブルがあり、幅が約150フィールド、行が約600mあり、多数のプロセスを駆動します。これはデータウェアハウスの状況にあるため、スケジュールされたロードプロセス以外では更新/挿入が行われないため、インデックスが大量に作成されます。 このテーブルをパーティション分割しようとする決定が下されており、パーティション分割されたテーブルのインデックス作成に関して懸念があります。私はパーティション分割の経験がないので、入力やリンクを歓迎します。私はBOLまたはmsdnで私が特に望んでいるものを見つけることができませんでした。 現在IncidentKey、varchar(50)一意であるとは呼ばないフィールドにクラスターを作成します。1〜100個の同じレコードを持つことができますIK（コメントは不要です）。古いIncidentKeyレコードで新しいデータを取得することが多いため、どちらもシーケンシャルではありません。 IncidentDateパーティションが正しく機能するためには、パーティション化フィールドをクラスター化インデックスキーに含める必要があることを理解しています。そうなると思っていますIncidentKey, IncidentDate。 問題は、「新しい」パーティションのレコードがクラスター化インデックスの「古い」パーティションのレコードの前にある場合、クラスター化インデックスの仕組みはパーティションテーブルの2パートキーでどのように機能するかです。 たとえば、5つのレコードがあります。 IncidentKey Date ABC123 1/1/2010 ABC123 7/1/2010 ABC123 1/1/2011 XYZ999 1/1/2010 XYZ999 7/1/2010 新しいレコードを取得する場合ABC123, 2/1/2011は、クラスター化インデックスのBEFORE にある必要がありXYZ999, 1/1/2010ます。これはどのように作動しますか？ 断片化とポインターを想定していますが、デュアルパートキーを持つパーティションテーブルの非パーティションクラスター化インデックスの物理ストレージと構成に関する情報が見つかりません。

16 sql-server  index  sql-server-2008-r2  partitioning 

ASP Web API、Entity Framework、およびSQL Server / Azureデータベースを使用して、マルチテナントアプリ（単一データベース、単一スキーマ）を構築しています。このアプリは、1000〜5000人の顧客が使用します。すべてのテーブルにはTenantId（Guid / UNIQUEIDENTIFIER）フィールドがあります。現在、私はId（Guid）という単一フィールドの主キーを使用しています。しかし、Idフィールドのみを使用することで、ユーザーから提供されたデータが正しいテナントからのものであるかどうかを確認する必要があります。たとえばSalesOrder、CustomerIdフィールドを持つテーブルがあります。ユーザーが販売注文を投稿/更新するたびにCustomerId、同じテナントからのものかどうかを確認する必要があります。各テナントに複数のコンセントがあるため、状況はさらに悪化します。次に、確認する必要がTenantIdありOutletIdます。これは本当にメンテナンスの悪夢であり、パフォーマンスに悪影響を及ぼします。 TenantIdとともに主キーに追加することを考えていIdます。また、おそらく追加OutletIdします。だから、主キーSalesOrder：テーブルになりますId、TenantIdとOutletId。このアプローチの欠点は何ですか？複合キーを使用すると、パフォーマンスが大幅に低下しますか？複合キーの順序は重要ですか？私の問題に対するより良い解決策はありますか？

16 sql-server  index  multi-tenant  design-pattern  physical-design 

実稼働データベースに525 GBのサイズのテーブルがあり、そのうち383 GBは未使用です。 このスペースの一部を回収したいのですが、実稼働DBをいじる前に、より少ないデータでテストDBの同一のテーブルでいくつかの戦略をテストしています。この表には同様の問題があります。 テーブルに関するいくつかの情報： フィルファクターは0に設定されます 約30列あります 列の1つはイメージタイプのLOBであり、数KBから数百MBのサイズのファイルを格納しています テーブルには仮想インデックスが関連付けられていません サーバーは、SQL Server 2017（RTM-GDR）（KB4505224）-14.0.2027.2（X64）を実行しています。データベースはSIMPLE復旧モデルを使用しています。 私が試したいくつかのこと： インデックスの再構築：ALTER INDEX ALL ON dbo.MyTable REBUILD。これによる影響はごくわずかです。 インデックスの再編成：ALTER INDEX ALL ON dbo.MyTable REORGANIZE WITH(LOB_COMPACTION = ON)。これによる影響はごくわずかです。 LOB列を別のテーブルにコピーし、列をドロップし、列を再作成し、データをコピーしました（この記事で概説したように、未使用スペースのSQL Serverテーブルの解放）。これにより、未使用のスペースが減少しましたが、使用済みのスペースに変換するだけのようです。 bcpユーティリティを使用して、テーブルをエクスポート、切り捨て、再読み込みします（この投稿で説明されているように、テーブルの未使用スペースを解放する方法）。これにより、未使用スペースが削減され、使用済みスペースが上のイメージと同程度に増加しました。 推奨されていませんが、DBCC SHRINKFILEおよびDBCC SHRINKDATABASEコマンドを試してみましたが、これらは未使用の領域に影響を与えませんでした。 実行DBCC CLEANTABLE('myDB', 'dbo.myTable')しても違いはありませんでした 画像とテキストのデータ型を維持しながら、データ型をvarbinary（max）とvarchar（max）に変更した後、上記のすべてを試しました。 新しいデータベースの新しいテーブルにデータをインポートしようとしましたが、これも未使用スペースを使用済みスペースに変換するだけでした。この投稿でこの試みの詳細を概説しました。 これらが期待できる結果である場合、実稼働DBでこれらの試行を行いたくないので、 これらの試行のいくつかの後、未使用スペースが使用済みスペースに変換されるのはなぜですか？私は内部で何が起こっているのかよく理解していないように感じます。 使用済みスペースを増やすことなく、未使用スペースを減らすためにできることは他にありますか？ 編集：テーブルのディスク使用量レポートとスクリプトは次のとおりです。 SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON …

15 sql-server  index  sql-server-2017  storage 

「実際の実行プランを含める」でクエリを実行すると、プランは欠落しているインデックスも提案します。インデックスの詳細はMissingIndexes、XML 内のタグです。計画に複数のインデックスの提案が含まれている状況はありますか？さまざまなSQLクエリを試しましたが、2つ以上の欠落インデックスを生成するクエリを思い付くことができませんでした。

15 sql-server  index  execution-plan 

という名前のテーブルがありAddress、そのテーブルには、という永続的な計算列がありHashkeyます。列は確定的ですが、正確ではありません。シークできない一意のインデックスがあります。このクエリを実行すると、主キーが返されます。 SELECT @ADDRESSID= ISNULL(AddressId,0) FROM dbo.[Address] WHERE HashKey = @HashKey 私はこの計画を取得します： インデックスを強制すると、さらに悪い計画が得られます。 インデックスとシークの両方を強制しようとすると、エラーが発生します。 このクエリで定義されたヒントのため、クエリプロセッサはクエリプランを作成できませんでした。ヒントを指定せずに、使用せずにクエリを再送信しますSET FORCEPLAN これは、正確ではないという理由だけですか？持続するかどうかは関係ないと思いましたか？ これを非計算列にすることなく、このインデックスをシーク可能にする方法はありますか？ これに関する情報へのリンクはありますか？ 実際のテーブル作成を投稿することはできませんが、同じ問題があるテストテーブルを次に示します。 drop TABLE [dbo].[Test] CREATE TABLE [dbo].[Test] ( [test] [VARCHAR](100) NULL, [TestGeocode] [geography] NULL, [Hashkey] AS CAST( ( hashbytes ('SHA', ( RIGHT(REPLICATE(' ', (100)) + isnull([test], ''), ( 100 )) ) + …

15 sql-server  sql-server-2012  index  optimization  computed-column 

WHERE条件付きのSQLクエリに使用するインデックスと、GROUP BY現在非常に遅いインデックスを決定しようとしています。 私のクエリ： SELECT group_id FROM counter WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0' GROUP BY group_id テーブルには現在32.000.000行があります。時間枠を増やすと、クエリの実行時間が非常に長くなります。 問題のテーブルは次のようになります。 CREATE TABLE counter ( id bigserial PRIMARY KEY , ts timestamp NOT NULL , group_id bigint NOT NULL ); 現在、次のインデックスがありますが、パフォーマンスはまだ遅いです。 CREATE INDEX ts_index ON counter USING btree (ts); …

15 postgresql  index  query-performance  optimization  postgresql-9.3 

SOで、誰かが最近インデックスを使用してORDER BYを使用しないのはなぜかと尋ねました。 この状況には、3つの列と1万行からなるMySQLの単純なInnoDBテーブルが含まれていました。列の1つである整数にインデックスが付けられ、OPはその列でソートされたテーブル全体を取得しようとしました。 SELECT * FROM person ORDER BY age 彼はEXPLAIN、このクエリがfilesort（インデックスではなく）で解決されたことを示す出力を添付し、その理由を尋ねました。 インデックスが使用される原因となるヒントに もかかわらず、誰かが（他からのコメント/賛成をサポートして）選択された列がすべてインデックスから読み取られたときにソートにのみ使用されると回答しました（つまり、通常は列に出力）。インデックスを走査してからテーブルからカラムをフェッチすると、ランダムI / Oが発生するという説明が後で与えられました。FORCE INDEX FOR ORDER BY (age) Using indexExtraEXPLAINfilesort これが表示されますが、上のマニュアルの章の顔に飛ぶためにORDER BY最適化だけでなく、満足していることに強い印象伝え、ORDER BYインデックスからすると、確かに（追加のソートを実行することが好ましいが、filesortクイックソートとマージソートの組み合わせで、それゆえ 必要があります下の結合しました;順番にインデックスを歩きながらテーブルをシークする必要があります-したがって、これは完全に理にかなっています）が、次のように述べながら、この「最適化」の申し立てを無視することもできません。Ω(nlog n)O(n) 次のクエリは、インデックスを使用してORDER BYパーツを解決します。 SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; 私の読書では、これはまさにこの状況の場合です（ただし、明示的なヒントなしにインデックスが使用されていませんでした）。 私の質問は： MySQLがインデックスを使用することを選択するために、選択されたすべての列にインデックスを付ける必要がありますか ある場合、これはどこに文書化されていますか（もしあれば）？ そうでない場合、ここで何が起こっていましたか？

15 mysql  index  innodb  order-by 

私の質問は、インデックスの使用に関するものです。 最初から、またはパフォーマンスの問題が発生したときに、インデックス作成を開始する必要がありますか？ クエリの実行中に一時インデックスを作成することもできます。そのような技術の長所と短所は何ですか？

15 performance  index  database-agnostic