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

idフィールドでクラスター化インデックスと非クラスター化インデックスを使用すると、ロックの動作が異なることに気付きながら、デッドロックの問題を解決しています。clustedインデックスまたはプライマリキーがidフィールドに適用されると、デッドロックの問題は解決されるようです。 異なる行に対して1つ以上の更新を実行する異なるトランザクションがあります。たとえば、トランザクションAはID = aの行のみを更新し、tx BはID = bの行のみを更新します。 そして、インデックスなしでは、更新はすべての行の更新ロックを取得し、必要に応じて排他ロックに変換し、最終的にデッドロックにつながることを理解しています。しかし、非クラスター化インデックスでは、デッドロックが依然として存在する理由を見つけることができません（ただし、ヒット率は低下しているようです） データ表： CREATE TABLE [dbo].[user]( [id] [int] IDENTITY(1,1) NOT NULL, [userName] [nvarchar](255) NULL, [name] [nvarchar](255) NULL, [phone] [nvarchar](255) NULL, [password] [nvarchar](255) NULL, [ip] [nvarchar](30) NULL, [email] [nvarchar](255) NULL, [pubDate] [datetime] NULL, [todoOrder] [text] NULL ) デッドロックトレース deadlock-list deadlock victim=process4152ca8 process-list process id=process4152ca8 taskpriority=0 …

13 sql-server  index  locking 

この回答によれば、制限に使用される列にインデックスが構築されない限り、クエリはインデックスの恩恵を受けません。 私にはこの定義があります： CREATE TABLE [dbo].[JobItems] ( [ItemId] UNIQUEIDENTIFIER NOT NULL, [ItemState] INT NOT NULL, [ItemPriority] INT NOT NULL, [CreationTime] DATETIME NULL DEFAULT GETUTCDATE(), [LastAccessTime] DATETIME NULL DEFAULT GETUTCDATE(), -- other columns ); CREATE UNIQUE CLUSTERED INDEX [JobItemsIndex] ON [dbo].[JobItems]([ItemId] ASC); GO CREATE INDEX [GetItemToProcessIndex] ON [dbo].[JobItems]([ItemState], [ItemPriority], [CreationTime]) INCLUDE (LastAccessTime); …

12 sql-server  index  execution-plan  azure-sql-database 

衛星データからの2つの地球測定値セットがあり、それぞれに時間フィールド（平均ユリウス日付のmjd）と地理的位置（GeoPoint、空間）があり、2つのセット間の一致が時間のしきい値に一致するように探しています3時間（または.125日）およびそれらの距離は互いに200 km以内です。 テーブルと空間テーブルの両方のmjdフィールドにインデックスを作成しました。 時間の制約に参加するだけで、データベースは8秒で100,000回の一致を計算し、その時間内のすべての100,000回の一致の距離を計算します。クエリは次のようになります。 select top 100000 h.Time, m.Time, h.GeoPoint.STDistance(m.GeoPoint)/1000.0 from L2V5.dbo.header h join L2.dbo.MLS_Header m on h.mjd between m.mjd-.125 and m.mjd+.125 option( table hint ( h, index(ix_MJD) ), table hint( m, index(ix_MJD) ) ) 実行された計画は次のとおりです。 並べ替えると、9つの距離が200km未満であったため、一致します。問題は、距離制約を追加して代わりにこれを実行すると、 select top 10 h.Time, m.Time, h.GeoPoint.STDistance(m.GeoPoint)/1000.0 from L2V5.dbo.header h join L2.dbo.MLS_Header m on …

12 sql-server  index  query-performance  join  spatial 

作業チケットのFirebird 2.5データベースを最適化しています。それらはそのように宣言されたテーブルに保存されます： CREATE TABLE TICKETS ( TICKET_ID id PRIMARY KEY, JOB_ID id, ACTION_ID id, STATUS str256 DEFAULT 'Pending' ); 通常、処理されておらずPendingステータスにある最初のチケットを見つけたいです。 私の処理ループは次のようになります： 最初のチケットを取得する場所 Pending チケットを使用してください。 チケットステータスの更新=> Complete 繰り返す。 派手なものは何もありません。このループの実行中にデータベースを監視している場合、各反復でインデックス付き読み取りの数が増えていることがわかります。パフォーマンスは、私が知ることができるほどひどく低下するようには見えませんが、私がテストしているマシンはかなり速いです。ただし、一部のユーザーから時間の経過とともにパフォーマンスが低下するという報告を受けました。 にインデックスがありますStatusが、それでもTicket_Id繰り返しごとに列をスキャンするようです。私は何かを見落としているように見えますが、何がわからないのですか。このようなものに対するインデックス付き読み取りの増加数は予想されていますか、それともインデックスが何らかの形で誤動作していますか？ -コメントの編集- Firebirdでは、次のように行の取得を制限します。 Select First 1 Job_ID, Ticket_Id From Tickets Where Status = 'Pending' だから、「最初」と言うとき、私はそれをどこに限定レコードセットを要求しているだけですStatus = 'Pending'。

12 performance  index  firebird 

クエリパフォーマンスの向上に関するこの質問に続き、デフォルトでインデックスを使用する方法があるかどうかを知りたいと思います。 このクエリは約2.5秒で実行されます。 SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; これは約33msで実行されます。 SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' ORDER BY [DateEntered], [DeviceID]; [ID]フィールド（pk）にクラスター化インデックスがあり、[DateEntered]、[DeviceID]に非クラスター化インデックスがあります。最初のクエリはクラスター化インデックスを使用し、2番目のクエリは非クラスター化インデックスを使用します。私の質問は2つの部分です。 なぜ、両方のクエリに[DateEntered]フィールドにWHERE句があるため、サーバーは2番目ではなく最初のクラスター化インデックスを使用するのですか？ orderbyがなくても、このクエリでデフォルトで非クラスタ化インデックスを使用するにはどうすればよいですか？（または、なぜそのような振る舞いを望まないのでしょうか？）

12 sql-server  sql-server-2008-r2  index  optimization 

無関係なインデックスを見つけるためにこのスクリプトを実行しています select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as SpaceInMB, s.* from sys.dm_db_index_usage_stats s inner join sys.objects o on s.object_id = o.object_id inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id = …

12 sql-server-2005  index 

Microsoftのデータベース開発試験70-433に関する本：Microsoft SQL Server 2008 Database Developmentによると： NOTロジックではなく先頭のワイルドカード文字のいずれも、クエリオプティマイザーがインデックスを使用して検索を最適化することを許可しません。最適なパフォーマンスを得るには、NOTキーワードと先頭のワイルドカード記号を使用しないでください。 することを取った私はそうNOT IN、NOT EXISTSなど さて、このSOの質問に関して、@ GBNが選んだ解決策は上記の声明に違反すると考えました。 どうやら、そうではありません。 だから私の質問は：なぜですか？

12 sql-server  index  optimization 

COUNT(*)非常に小さくインデックスが付けられた主キーがあるのに、PostgreSQLがクエリのためにテーブルを順番にスキャンするのはなぜですか？

12 postgresql  index  count 

明らかに、いくつかの異なるインデックスを保持することは、挿入および削除のパフォーマンスに悪影響を及ぼします。クエリのパフォーマンスはどうですか：テーブルに多くのインデックスを保持するのは理にかなっていますか？インデックスを追加するとクエリのパフォーマンスが向上しますか（もちろん、インデックスを使用するクエリの場合）、取得するためにすべてのインデックスを調べる必要があるため、インデックスが多すぎるとクエリのパフォーマンスが低下する可能性があります結果？ テーブルに異なるインデックスがある場合：それらはすべて考慮されるのか、オプティマイザーの観点からのみ最適なのか？Oracleは多次元インデックスを実装していますか？

12 oracle  performance  index 

フルテキストインデックスを最新の状態に保つためのデータベーステーブルがあります。ただし、これが発生しているのはまったくわかりません（最後に表示されたログは手動でトリガーしたときだったため、ログにエラーはありません）。 これが私が見ているものです... テーブルの上に... これが自動的に行われない理由ですか？

12 sql-server-2012  index  full-text-search  change-tracking 

私はこのようなテーブルを持っています： CREATE TABLE products ( id serial PRIMARY KEY, category_ids integer[], published boolean NOT NULL, score integer NOT NULL, title varchar NOT NULL); 製品は複数のカテゴリに属する​​ことができます。category_ids列は、すべての製品のカテゴリのIDのリストを保持します。 典型的なクエリは次のようになります（常に単一のカテゴリを検索します）： SELECT * FROM products WHERE published AND category_ids @> ARRAY[23465] ORDER BY score DESC, title LIMIT 20 OFFSET 8000; スピードアップするには、次のインデックスを使用します。 CREATE INDEX idx_test1 ON products …

12 postgresql  index  postgresql-performance 

array列に上限はありますか？ 配列フィールドに挿入すると、このエラーが発生します- PG::Error: ERROR: index row size 3480 exceeds maximum 2712 for index "ix_data" これが私のテーブル定義です- create table test_array(id varchar(50), data text[]); ALTER TABLE test_array ADD PRIMARY KEY (id); CREATE INDEX ix_data ON test_array USING GIN (data); 配列フィールドを検索しているので、配列フィールドにインデックスが必要です。

12 performance  postgresql  database-design  index  postgresql-9.1 

2億行以下、15列以下のテーブルがあります。COLUMNSTOREテーブルにインデックスを作成する予定です。 列ストアインデックスで使用する列の順序に基づいてパフォーマンスに変化はありますか？はいの場合、その背後にあるロジックは何ですか？

12 sql-server  database-design  sql-server-2012  index  columnstore 

2つ以上の列の複合主キーを作成する場合PRIMARY KEY(col1, col2, col3)。システムはINDEX各列を個別に使用しますか？ 私はこの質問をしていた理由は、私たちが使用している場合ということですUNIQUE INDEX (col1, col2, col3)、それはとして機能するINDEXだけで、最初の列のために、私たちは、追加作成する必要がありINDEX、他の列に対して複数可。それが複合主キーにも当てはまるかどうかを知りたいです。

12 mysql  index  primary-key 

FORCEインデックスに関する記事を読みましたが、MySQLを強制的にIGNORE ALLインデックス化するにはどうすればよいですか？ 試しましたがSELECT * FROM tbl IGNORE INDEX(*)、うまくいきませんでした。 なぜ私（および他の人）がこれを行う必要があるのか​​については、たとえば、次のようにtldでリファラー統計を要約する必要がありました。 SELECT count(*) as c, SUBSTRING ( domain_name, LENGTH(domain_name) - LOCATE('.', REVERSE(domain_name)) + 2 ) as tld FROM `domains_import` IGNORE INDEX(domain_name) GROUP BY tld ORDER BY c desc LIMIT 100 ...しかし、私は常に定義されているインデックスを確認するか、Explainを使用してどのインデックスを使用するかを決定する必要があります。単に書いてIGNORE INDEX ALL、気にしないのは非常に便利です。 誰かが構文やハックを知っていますか？（MySQL定義テーブルを介した数十行は、実際にはショートカットではありません）。 チャットディスカッションから追加： Bechmark： インデックスなし= 148.5秒 インデックス= 180秒で、まだデータの送信で実行中SSDアレイは非常に強力であるため、データキャッシュはほとんど気にしません... ベンチマークの定義： CREATE …

12 mysql  index  mysql-5.6