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

私はこのクエリを持っています： SELECT * FROM location WHERE to_tsvector('simple',unaccent2("city")) @@ to_tsquery('simple',unaccent2('wroclaw')) order by displaycount 私はそれに満足しています： "Sort (cost=3842.56..3847.12 rows=1826 width=123) (actual time=1.915..2.084 rows=1307 loops=1)" " Sort Key: displaycount" " Sort Method: quicksort Memory: 206kB" " -> Bitmap Heap Scan on location (cost=34.40..3743.64 rows=1826 width=123) (actual time=0.788..1.208 rows=1307 loops=1)" " Recheck Cond: (to_tsvector('simple'::regconfig, unaccent2((city)::text)) …

11 postgresql  performance  index  full-text-search 

Postgresカラムに一意の制約を作成すると、インデックスを付ける必要がなくなりますか？ 制約を効率的に維持するには、インデックスが自動的に必要になると思います。

11 postgresql  database-design  index  unique-constraint 

特定のインデックスの作成を提案する、欠落したインデックスDMVの原因となっているクエリをどのようにして見つけることができますか？ ありがとうございました。

11 sql-server  sql-server-2008  sql-server-2008-r2  index  dmv 

SQL Serverデータベースに、主キーにクラスター化インデックスを持つテーブルがあります。テーブルには100万行あります。テーブルから10K行を削除した場合、削除操作の実行中にインデックスが再構築されますか？ 削除操作はストアドプロシージャの一部です。一度に複数のクライアントがストアドプロシージャを実行できますが、個々の実行ごとに独自の行のセット（主キーによって一意に識別される）が削除されます。複数のクライアントがプロシージャを実行すると、キーロック（タイプU）がブロックされます。ブロッカーロックは同じテーブルの行に属しており、同時に実行されているトランザクションの一部ではありません。各実行はそれ自体の行のセットを削除しようとしているため、ブロックはありません。ロックのエスカレーションはオフになっているため、発生していません。 削除操作によってインデックスが再調整されるため、再構築プロセス中にテーブルの任意の行でキーロックが発生する可能性があると思います。 これについてのご意見をいただければ幸いです。

10 sql-server  index  optimization 

次のスクリプトを実行するとエラーが発生します。 IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME='Table_Name') BEGIN CREATE TABLE Table_Name ( Field_Name_1 binary(32) NOT NULL CONSTRAINT PK_Name_Goes_Here PRIMARY KEY NONCLUSTERED , Field_Name_2 int NOT NULL , Field_Name_3 datetime NOT NULL INDEX IX_Name_Goes_Here CLUSTERED ) END 特に、次のエラーをスローするクラスター化インデックスの作成です。 メッセージ1018、レベル15、状態1、行15 「INDEX」付近の構文が正しくありません 。これがテーブルヒントの一部として意図されている場合、WITHキーワードと括弧が必要になりました。適切な構文については、SQL Server Books Onlineを参照してください。 特定のQAサーバーを除くすべてのサーバーで機能するため、これは奇妙です。私たちが行った修正は、テーブル作成ステートメントの外でクラスター化インデックスを作成することですが、誰かが以前にこの問題に遭遇したことがあれば、興味がありますか？

10 sql-server  sql-server-2012  index  ddl  clustered-index 

SQL Serverが非永続計算列を実際に格納する方法に関するドキュメントを見つけるのに苦労しています。 次の例を見てください。 --SCHEMA CREATE TABLE dbo.Invoice ( InvoiceID INT IDENTITY(1, 1) PRIMARY KEY, CustomerID INT FOREIGN KEY REFERENCES dbo.Customer(CustomerID), InvoiceStatus NVARCHAR(50) NOT NULL, InvoiceStatusID AS CASE InvoiceStatus WHEN 'Sent' THEN 1 WHEN 'Complete' THEN 2 WHEN 'Received' THEN 3 END ) GO --INDEX CREATE NONCLUSTERED INDEX IX_Invoice ON Invoice …

10 sql-server  sql-server-2012  index  computed-column 

問題 次のようなクエリがあります SELECT COUNT(1) FROM article JOIN reservation ON a_id = r_article_id WHERE r_last_modified < now() - '8 weeks'::interval AND r_group_id = 1 AND r_status = 'OPEN'; （10分後に）タイムアウトになることが多いため、この問題を調査することにしました。 EXPLAIN (ANALYZE, BUFFERS)出力は次のようになります。 Aggregate (cost=264775.48..264775.49 rows=1 width=0) (actual time=238960.290..238960.291 rows=1 loops=1) Buffers: shared hit=200483 read=64361 dirtied=666 written=8, temp read=3631 written=3617 I/O Timings: …

10 postgresql  index  postgresql-9.3  execution-plan 

以下のフィルターされたインデックスを作成しましたが、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 

私はそれを言っているこの本を読んでいます データベースは、Indexed_Col IS NOT NULLがカバーする範囲が大きすぎて役に立たないと想定しているため、データベースはこの状態からインデックスに移動しません。 この本は10年以上前のものであると認識していますが、すでに非常に有用であることが証明されています。 さらに、クエリを実行EXPLAIN ANALYZEしSELECTているときに、自分のインデックスがまったく使用されていないことがわかりました。 したがって、私の質問は： 列が "NOT NULL"を含む列を持つテーブルがあり、この列をカバーするインデックスが存在する場合、このインデックスは、列がクエリの一部であるテーブルのクエリで使用されますか？ お気に入り： CREATE TABLE my_table( a varchar NOT NULL ); CREATE INDEX ix_my_table ON my_table(a); SELECT a from my_table;

10 postgresql  index  index-tuning  postgresql-9.1 

クレイグ・リンガーによると： 通常、参照側の外部キー列（またはそれを含む）にインデックスを作成することをお勧めしますが、必須ではありません。追加するインデックスごとにDML操作が少し遅くなるためINSERT、UPDATEまたはごとにパフォーマンスコストが発生しDELETEます。インデックスがめったに使用されない場合、その価値はないかもしれません。 インデックスを追加するメリットがコストを上回るかどうかをどのように判断しますか？ インデックスを追加する前後に単体テストのプロファイルを作成し、全体的なパフォーマンスの向上を確認しますか？それとももっと良い方法がありますか？

10 postgresql  index  optimization 

Inno-Tablesでのインポート速度に関する私の前の質問のフォローアップがあります（驚き！）。 シナリオ 私は妥当な時間内にローカルの開発用マシンにいくつかのbig *データベースダンプをインポートしようとしました。KEYテーブルに接続されている多くのがボトルネックになっていますが、それでもライブシステムにとって重要です。 上記の質問をした後の私のアプローチはKEY ...、ダンプからステートメントを削除し、キーをインポートして再度追加することでした。 しかし、現在のダンプを編集してローカルにインポートすることがよくあり、これらの面白い "コメント"に遭遇しました（- disable/enable keys行）。 -- -- Dumping data for table `monster` -- LOCK TABLES `monster` WRITE; /*!40000 ALTER TABLE `monster` DISABLE KEYS */; INSERT … INSERT … INSERT /*!40000 ALTER TABLE `monster` ENABLE KEYS */; UNLOCK TABLES; しかし、実際にはこれらの「コメント」は条件付きのMySql-Statementsです それは私にとってはニュースでしたが、出力フォームを考えると、mysql --versionすべてが私には問題なく見えます。 mysql Ver 14.14 Distrib …

10 mysql  index  backup  innodb  mysqldump 

更新：tl; dr：問題はMySQLがTMPDIRインデックスの作成時にを使用することでした。そして私TMPDIRはディスク容量が足りなくなった。 元のQ： InnoDBテーブルにインデックスを追加しようとしていて、を取得していtable is full errorます。十分なディスク容量があり、MySQL構成にはfile-per-table = 1があります。テーブルデータは85GBで、インデックスは約20GB-30GBであり、それよりもはるかに多くのディスク容量があると思います。私はext3も使用しているので、OSの観点からはファイルサイズの制限に問題はないと思います。 ログに記録されたエラーは次のようになります。 140616 13:04:33 InnoDB: Error: Write to file (merge) failed at offset 3 1940914176. InnoDB: 1048576 bytes should have been written, only 970752 were written. InnoDB: Operating system error number 0. InnoDB: Check that your OS and file system support files …

10 mysql  innodb  index 

奇妙なことに、私のストアード・プロシージャーは、一部の入力データについてメッセージ666を受け取り始めました。 次の構造を持つテーブルに行を挿入しようとすると、最後のステップでストアドプロシージャが失敗します。 Columns: A_Id: PK, int B_Id: PK, FK, int C_Id: PK, FK, int D_Id: PK, smallint これは基本的に、参照されるすべてのエンティティを接続するテーブルです。 Indexes: IX_TableName_D_id - Clustered index on D_id column PK_TableName - Unique non-clustered index on all columns (A_Id, B_Id, C_Id, D_Id) 両方のインデックスの断片化は低い（25％未満）。ただし、テーブルに対する操作の量が非常に多いため、PK_TableNameの断片化は急速に増大します。 テーブルサイズ： Row count: ~80,000,000 rows したがって、veeery simpleクエリを実行しようとすると、一部のD_Idに対して次のメッセージが表示されます。 メッセージ666。パーティションID 422223771074560のインデックスで、重複グループのシステム生成の一意の最大値を超えました。インデックスを削除して再作成すると、これが解決する場合があります。それ以外の場合は、別のクラスタリングキーを使用します。 クエリ例： INSERT …

10 sql-server  sql-server-2008  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 

auto_review列のタイプがと呼ばれるデータベース列がありますboolean。ActiveRecord ORMを使用して作成された、そのフィールドのインデックスがあります。 CREATE INDEX index_table_on_auto_renew ON table USING btree (auto_renew); フィールドにブール値を照会すると、PGは期待どおりにインデックスを使用します。 EXPLAIN for: SELECT "table".* FROM "table" WHERE "table"."auto_renew" = 'f' QUERY PLAN ---------------------------------------------------------------------------------------------- Bitmap Heap Scan on table (cost=51.65..826.50 rows=28039 width=186) Filter: (NOT auto_renew) -> Bitmap Index Scan on index_domains_on_auto_renew (cost=0.00..44.64 rows=2185 width=0) Index Cond: (auto_renew = false) (4 …

10 postgresql  index  postgresql-9.1  postgresql-8.3