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

実行速度の遅いクエリをデバッグしています。実行プランでは、非クラスタ化インデックスが推奨され、51.6648の影響があります。ただし、非クラスター化インデックスには、主キー（PK）複合クラスター化インデックスに既に含まれている列のみが含まれます。 これは、インデックス内の列の順序が原因である可能性がありますか？つまり、クラスター化インデックスの列の選択性が最も高いものから低いものへの順序ではない場合、非クラスター化インデックスがパフォーマンスを向上させる可能性はありますか？ さらに、非クラスター化インデックスには3つのPK列のうち2つだけが含まれ、3番目の列は包含列として追加されます。あるinclude非クラスタ化インデックスの使用がより最適かもしれないもう一つの理由？ 以下は、私が使用しているテーブル構造の例です。 テーブル- Retailers ( RetailerID int PK, name ...) Retailer_Relation_Types ( RelationType smallint PK, Description nvarchar(50) ...) Retailer_Relations ( RetailerID int PK FK, RelatedRetailerID int PK FK, RelationType smallint PK FK, CreatedOn datetime ...) テーブルにRetailer_Relationsは、次の複合PKインデックスと推奨インデックスがあります。 CONSTRAINT PK_Retailer_Relations PRIMARY KEY CLUSTERED ( RetailerID ASC, RelatedRetailerID ASC, RelationType ASC …

9 sql-server  index  sql-server-2016  execution-plan 

私は、order byなしのselectステートメントを実行するときに、テーブルの行が挿入された順序になるようにしたいと考えている開発者がいます。開発者は、クラスター化インデックスから非クラスター化インデックスへの変更を提案しました。 インデックスをクラスター化から非クラスター化に変更することで、テーブルに行が表示される順序について何か保証はありますか？ この質問は主に私の好奇心です。代わりにID列を使用することをお勧めしますが、このリクエストは私に考えさせられました。タイムスタンプを使用できますが、行を同時に挿入できる可能性があります。 よろしくお願いします。

9 sql-server  index  clustered-index  nonclustered-index 

私の開発者の1人は、これCOALESCE(column, default value) = default valueが現在は反論の余地があると主張しています。そうですか？ 私は次のテストを実行しましたが、それがCOALESCE反論できないことを意味すると思います。 USE tempdb; SELECT @@VERSION; -- Microsoft SQL Server 2016 (RTM-CU3-GDR) (KB3194717) - 13.0.2186.6 (X64) Oct 31 2016 18:27:32 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows 10 Pro 6.3 <X64> (Build 14393: ) (Hypervisor) CREATE TABLE Test ( ID int primary key …

9 sql-server  index  sql-server-2016 

PostgreSQLにいくつかのデータを含むテーブルがあります。 create table t2 ( key jsonb, value jsonb ); INSERT INTO t2(key, value) VALUES ('1', '"test 1"') ,('2', '"test 2"') ,('3', '"test 3"') ,('[]', '"test 4"') ,('[1]', '"test 5"') ,('[2]', '"test 6"') ,('[3]', '"test 7"') ,('[1, 2]', '"test 8"') ,('[1, 2, 3]', '"test 9"') ,('[1, 3]', '"test 10"') ,('[1,2,4]', …

9 postgresql  index  order-by  json  array 

インデックスまたはテーブルスキャンを使用する場合、SQL Serverは統計を使用してどちらが優れているかを確認します。 2,000万行のテーブルがあります。（SnapshotKey、Measure）のインデックスと次のクエリがあります。 select Measure, SnapshotKey, MeasureBand from t1 where Measure = 'FinanceFICOScore' group by Measure, SnapshotKey, MeasureBand クエリは500k行を返します。したがって、クエリはテーブルの行の2.5％のみを選択します。 問題は、SQL Serverが私が持っている非クラスター化インデックスを使用せず、代わりにテーブルスキャンを使用する理由です。 統計を更新しました。 ただし、クエリのパフォーマンスは良好です。 テーブルスキャン 強制インデックス テーブル/インデックス構造 CREATE TABLE [t1]( [SnapshotKey] [int] NOT NULL, [SnapshotDt] [date] NOT NULL, [Measure] [nvarchar](30) NOT NULL, [MeasureBand] [nvarchar](30) NOT NULL, -- and many more fields …

9 sql-server  sql-server-2012  index  optimization  execution-plan 

SELECTステートメントを最適化する必要がありますが、SQL Serverはシークではなく常にインデックススキャンを実行します。これはもちろん、ストアドプロシージャ内にあるクエリです。 CREATE PROCEDURE dbo.something @Status INT = NULL, @IsUserGotAnActiveDirectoryUser BIT = NULL AS SELECT [IdNumber], [Code], [Status], [Sex], [FirstName], [LastName], [Profession], [BirthDate], [HireDate], [ActiveDirectoryUser] FROM Employee WHERE (@Status IS NULL OR [Status] = @Status) AND ( @IsUserGotAnActiveDirectoryUser IS NULL OR ( @IsUserGotAnActiveDirectoryUser IS NOT NULL AND ( @IsUserGotAnActiveDirectoryUser = …

9 sql-server  sql-server-2012  index  optimization 

Mac（10.10.4）でpostgres（postgis）9.4.2を実行しています。 私はいくつかの大きなテーブル（数TB）を持っています。 そのうちの1つで約1週間かかるインデックス作成中に、停電がバッテリーユニットとシステムよりも長く続いたときにインデックスが終了するポイントに近いと予想されるので、利用可能なHDスペースの低下を観察しました降りた。fillfactor=100静的データソースであるため、私はバッファをオフにしていて、ビルド中にそれを行いました。再起動時に、ドライブに残っている使用可能なスペースは、インデックスビルドのほぼ終了時とまったく同じです。真空分析はスペースを解放しません。 テーブルを落として再度取り込みましたが、スペースは落ちませんでした。現在、インデックスを作成するための十分なスペースがない場所にいます。 インデックスの構築中に生成されたファイルは、停電中にマシンがダウンした方法が原因でシステムによって削除できない場所でスタックしていますか？ テーブルサイズとデータベース内のインデックス（そのドライブ上の唯一のデータ）を見ると、合計で約6TBです。ドライブです8TB未満、そこにある500ギガバイトは、インデックスがあったであろうという大きさです1.5TB失われたどこかに約あるようですので、ドライブに残しました。 何か案は？

9 postgresql  index  postgresql-9.4  disk-space  vacuum 

約1,000万行のテーブルと日付フィールドのインデックスがあります。結果セットに26項目しかない場合でも、インデックス付きフィールドの一意の値を抽出しようとすると、Postgresは順次スキャンを実行します。オプティマイザがこの計画を選ぶのはなぜですか？そして、私はそれを避けることができますか？ 他の答えから、これはインデックスと同じくらいクエリに関連していると思います。 explain select "labelDate" from pages group by "labelDate"; QUERY PLAN ----------------------------------------------------------------------- HashAggregate (cost=524616.78..524617.04 rows=26 width=4) Group Key: "labelDate" -> Seq Scan on pages (cost=0.00..499082.42 rows=10213742 width=4) (3 rows) テーブル構造： http=# \d pages Table "public.pages" Column | Type | Modifiers -----------------+------------------------+---------------------------------- pageid | integer | not null default nextval('... …

9 postgresql  index  query-performance  postgresql-9.4 

免責事項：データベースの内部に関する知識が不足していることをお許しください。ここに行く： データベースの定期的なクリーンアップジョブで大きなパフォーマンスの問題があるアプリケーション（私たちが作成したものではありません）を実行します。クエリは次のようになります。 delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); わかりやすく、読みやすく、標準SQL。しかし、残念ながら非常に遅いです。クエリを説明すると、既存のインデックスVARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_IDが使用されていないことがわかります。 mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( -> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY -> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); | id | select_type | table | type | possible_keys | key | …

9 mysql  index  join  delete  optimization 

大規模なパーティションOLAPテーブルを管理する特権があります。この表を確認したところ、インデックスの1つがパーティションスキームと一致していないことに気付きました。著者が利用できず、注意深く作成されたGoogle検索で有用な結果が返されなかったため、これが意図的なものか偶発的なものかはわかりません。 SQL Server 2008でインデックスをパーティションアラインしない理由はありますか？

9 sql-server  sql-server-2008  index  partitioning 

私のアプリでは、dbとアプリの間の往復回数が減ったという理由だけで、可能な場合は複数行の挿入を行います。 しかし、気になったのですが、他にメリットはありますか？たとえば、次のように複数の行が一度に挿入された場合： insert into tbl (c1, c2) values (v1, v2) (v3, v4) 対： insert into tbl (c1, c2) values (v1, v2) insert into tbl (c1, c2) values (v3, v4) テーブルにインデックスがありますが、最初のケースではインデックスが1回計算され、2番目のケースでは2回計算されますか？それとも、挿入ごとに常に1回ですか？両方のクエリが同じトランザクションにあると仮定します。 PostgreSQLを使用しています。

9 postgresql  index  optimization 

最近、いくつかの興味深いインデックスの問題がある一連のデータベースの保守に携わってきました。私を最も悪化させるものの1つは、開発、テスト、モデル、および生産マシン間のインデックスの違いです。違いによりクエリのチューニングが難しくなるため、クエリの同期は私の最初のプロジェクトの1つです。 テスト環境とモデル環境を比較したところ、モデル環境のほとんどのインデックスがSTATISTICS_NORECOMPUTE設定されているのONに対し、テスト環境のインデックスはそうではないことに気付きました。すべての環境で、すべてのデータベースの統計を更新する夜間ジョブがあります。 私はこれまでに対処したことがないSTATISTICS_NORECOMPUTEので、ここに私の質問があります。この設定を扱う際のベストプラクティスはありますか？1日の終わりに統計の更新を行っている場合STATISTICS_NORECOMPUTE、すべての環境ですべてのインデックスをオンにするのが最善ですか？それとも、正当な理由がないのですか？ 編集：私はここでこの件に関するキンバリートリップのブログの1つを見つけましたが、それSTATISTICS_NORECOMPUTEはせいぜい控えめに使用する必要があることを示唆しているようです。しかし、私はまだそれをグローバルにオフにすることを心配しています。誰かがこれを試しましたか、そして彼らは何を経験しましたか？

9 sql-server  sql-server-2008-r2  index  statistics 

大量のデータを空のデータベースにインポートしています。開始する前に、一意でない非クラスター化インデックスをすべて無効にして、インポートのパフォーマンスを向上できるかどうかを確認しました。 ここで、インデックスを再度有効にしたいと思います。これを最適化するために何かできることがあるかどうか疑問に思っています。 再構築する必要がある100を超えるテーブルとほぼ2,000のインデックスがあります。データベースのサイズは200GBです。 私が実行しているスクリプトの重要なセクションは次のとおりです。 declare c_toggle_index cursor FORWARD_ONLY READ_ONLY for select 'alter index ' + QUOTENAME(i.name) + ' on ' + o.name + ' rebuild' from sys.indexes as i Inner Join sys.objects o On o.object_id = i.object_id Where o.is_ms_shipped = 0 And i.index_id >= 1 and i.type > 1 and …

9 sql-server-2008-r2  index  import 

PostgreSQLがディスク上のレコードをどのように並べるかを知る必要があります。この場合、docsに記載されているインデックスの組み合わせを利用したいと思います。これは、ビットマップを使用して一致する行を取得し、物理的な場所に従ってそれらを返すことを理解しています。問題のテーブルは、主キーによってクラスター化されています。 私が理解しているように、PostgreSQLはクラスタリングが終了した後、自動的にクラスタリングを継続しません（ただし、特定のインデックスに従ってクラスタリングされたことを覚えています）。さて、これが主キーなので、物理的なストレージの順序はそれに従っているのでしょうか（これがtrueの場合は、特定のクエリに有利に使用したいと思います）。 要約すると、特にクラスタリングの後、PostgreSQLは新しいレコードをどのように順序付けますか？ どうもありがとう！

9 postgresql  database-design  index  clustered-index  physical-design 

アプリケーション開発時に、私はテーブルの多くを持っている（通常は10〜40個の値、データのストア「小さな」量id+ value時々とtype同様に、「オブジェクト」の属性ホールド）新鮮/腐った、赤/緑/青の製品について。 電子コンポーネントを新しくすることはできず、酸素ガスを赤くすることはできず、テーブルは無制限の行数を持つことができないので、この属性を製品テーブルに入れません... 属性を格納するために、私は、カスタム小さなテーブルを使用します。ここで、2-3フィールド：id、リンクするためのnameアプリケーションで表示するためといつかtype同じカテゴリ内の属性グループ場合。 主要な「オブジェクト」は、中間の多対多のテーブルを介して属性にリンクされています。 アイテム数が1000未満（通常は10〜40）の「小さな辞書」のインデックスを作成して維持する理由はありますか？ 私のターゲットデータベースはOracleですが、ベンダーに依存しないことを願っています... 私は記入-いいえ、しかし私の記入を正当化する技術的スキルはありません...

9 index  index-tuning