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

要約は次のとおりです。選択クエリを実行しています。WHEREand ORDER BY句のすべての列IX_MachineryId_DateRecordedは、キーの一部として、またはINCLUDE列として、単一の非クラスター化インデックスに含まれます。すべての列を選択しているので、ブックマークルックアップTOP (1)になりますが、を取得するだけなので、サーバーはルックアップを最後に一度だけ実行する必要があることを確認できます。 最も重要なことは、クエリでindexを使用するように強制するとIX_MachineryId_DateRecorded、1秒未満で実行されることです。使用するインデックスをサーバーに決定させると、サーバーが選択しIX_MachineryId、最大1分かかります。これは、私がインデックスを正しく作成したことを本当に示唆しており、サーバーは単に悪い判断を下しています。どうして？ CREATE TABLE [dbo].[MachineryReading] ( [Id] INT IDENTITY (1, 1) NOT NULL, [Location] [sys].[geometry] NULL, [Latitude] FLOAT (53) NOT NULL, [Longitude] FLOAT (53) NOT NULL, [Altitude] FLOAT (53) NULL, [Odometer] INT NULL, [Speed] FLOAT (53) NULL, [BatteryLevel] INT NULL, [PinFlags] BIGINT NOT NULL, [DateRecorded] DATETIME NOT …

15 sql-server  index  azure-sql-database  nonclustered-index 

テーブルにtは2つのインデックスがあります。 create table t (a int, b int); create type int_pair as (a int, b int); create index t_row_idx on t (((a,b)::int_pair)); create index t_a_b_idx on t (a,b); insert into t (a,b) select i, i from generate_series(1, 100000) g(i) ; any演算子ではインデックスは使用されません。 explain analyze select * from t where (a,b) = …

15 postgresql  index  optimization  postgresql-9.4  execution-plan 

128ビットUUIDを保存するには、複数の保存オプションがあります。 byte [16]列 2つのbigint / long（64ビット）列 CHAR（36）列-32桁の16進数+ 4つのダッシュ。 dbがサポートしている場合、UUIDデータベース固有の列 インデックスの観点から、どれが最も効率的ですか？データベースが専用のuuidタイプをサポートしていない場合、1、2、3のうちどれが最適な候補ですか？

15 sql-server  mysql  oracle  postgresql  index 

画像のハッシュを含む大規模なデータベース（16M行）があります。 妥当な時間枠で距離をハミングすることで行を検索できるようにしたいと思います。 現在、私が問題を適切に理解している限り、ここでの最良の選択肢はBK-Treeを実装するカスタムSP-GiST実装だと思いますが、それは多くの作業のように思われ、まだ実用的ではありませんカスタムインデックスの適切な実装の詳細。ハミング距離を計算すると、扱いやすい十分です、と私はやるけれども、Cを知っています。 基本的に、ここでの適切なアプローチは何ですか？ハッシュの特定の編集距離内で一致を照会できる必要があります。私が理解しているように、等しい長さの文字列を持つレーベンシュタイン距離は機能的にハミング距離です。そのため、そこからインデックスを作成する明確な方法はありませんが、少なくともいくつかの既存のサポートがあります（私が照会している値を思い出してください）変更：固定値からの距離を事前に計算することはできません。 ハッシュは現在、ハッシュのバイナリASCIIエンコード（たとえば「10010101 ...」）を含む64文字の文字列として格納されていますが、十分簡単に​​int64に変換できます。本当の問題は、比較的高速にクエリできる必要があるということです。 私が望むものの線に沿って何かを達成することは可能だと思わpg_trgmれますが、トライグラムマッチングメカニズムがどのように機能するかについては少しわかりません（特に、それが返す類似性メトリックは実際に何を表しますか？編集距離のようなもの）。 挿入のパフォーマンスは重要ではありません（各行のハッシュを計算するのは非常に計算コストがかかります）ので、私は主に検索を気にします。

15 postgresql  index  postgresql-9.3 

私は実行しEXPLAINます： mysql> explain select last_name from employees order by last_name; +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-----------+------+---------------+------+---------+------+-------+----------------+ | 1 | SIMPLE | employees | ALL | NULL | NULL | NULL | NULL | …

14 mysql  innodb  index  optimization  explain 

クエリがかなり遅いSQL Serverデータベースがあり、ロックとブロックがたくさんあります。 欠落しているインデックスDMVとクエリプランを見ると、提案はありません。 何故ですか？

14 sql-server  performance  index 

alter tableのpostgresのドキュメントを見ると、通常の制約はDEFERRABLE（より具体的には、INITIALLY DEFERRED、これが私が興味を持っていることです）。 次の条件を満たしている限り、インデックスを制約に関連付けることもできます。 インデックスには式列を含めることも、部分インデックスにすることもできません そのため、現在、次のような条件付きの一意のインデックスを作成する方法はないと考えています。 CREATE UNIQUE INDEX unique_booking ON public.booking USING btree (check_in, check_out) WHERE booking_status = 1; であるためにINITIALLY DEFERRED（場合一意「制約」は唯一のトランザクションの最後に検証されることを、意味し、SET CONSTRAINTS ALL DEFERRED;使用されています）。 私の仮定は正しいですか、もしそうなら、意図した動作を達成する方法はありますか？ ありがとう

14 postgresql  index  transaction  unique-constraint 

（偽の）人の名前を含む、それぞれ50,000行の2つのテーブルを持つsqliteデータベースがあります。両方のテーブルに共通する名前（名前、ミドルネームのイニシャル、姓）がいくつあるかを調べる簡単なクエリを作成しました。 select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial; 主キー以外にインデックスがない場合（このクエリとは無関係）、すぐに実行されます。 [james@marlon Downloads] $ time sqlite3 generic_data_no_indexes.sqlite "select count(*) from fakenames_uk inner join fakenames_usa on fakenames_uk.givenname=fakenames_usa.givenname and fakenames_uk.surname=fakenames_usa.surname and fakenames_uk.middleinitial=fakenames_usa.middleinitial;" 131 real 0m0.115s user 0m0.111s sys 0m0.004s しかし、各テーブルの3つの列にインデックスを追加する場合（全部で6つのインデックス）： CREATE INDEX `idx_uk_givenname` ON `fakenames_uk` (`givenname` ) //etc. …

14 performance  index  optimization  sqlite  count 

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 

次のスキーマとサンプルデータの場合 CREATE TABLE T ( A INT NULL, B INT NOT NULL IDENTITY, C CHAR(8000) NULL, UNIQUE CLUSTERED (A, B) ) INSERT INTO T (A) SELECT NULLIF(( ( ROW_NUMBER() OVER (ORDER BY @@SPID) - 1 ) / 1003 ), 0) FROM master..spt_values アプリケーションは、このテーブルの行をクラスター化インデックスの順序で1,000行のチャンクで処理しています。 最初の1,000行は、次のクエリから取得されます。 SELECT TOP 1000 * FROM T …

14 sql-server  index 

私たちのデータベースには、次のような多かれ少なかれ大きなテーブルがあります。 CREATE TABLE dbo.production_data ( pd_id BIGINT PRIMARY KEY, serial NVARCHAR(16) NOT NULL UNIQUE, ... ); しかし、今ではシリアルフィールドのサイズが小さくなっているので、32に変更したいと思います。VisualStudioスキーマ比較ツールは、これを行うことを提案します。 DROP INDEX ux_production_data_serial ON dbo.production_data; GO ALTER TABLE dbo.production_data ALTER COLUMN serial NVARCHAR(32) NOT NULL; GO CREATE INDEX ux_production_data_serial ON dbo.production_data(serial ASC); これは本当に必要ですか？それとも、これを行う超保存的な方法のようなものですか？ また、一意のインデックスを再作成すると、テーブルがロックされますか？これは大きな問題になるためです（テーブルには3,000万行あり、インデックスの再作成にはかなり時間がかかると思います）。これは、次のメンテナンスウィンドウが数か月先になるためです。私の選択肢は何ですか？

14 sql-server  index  locking  alter-table  unique-constraint 

メンテナンスジョブ中に、断片化されたインデックスのリストを取得しようとしています。しかし、クエリは非常に遅く、実行に30分以上かかります。これはsys.dm_db_index_physical_statsのリモートスキャンによるものだと思います。 次のクエリを高速化する方法はありますか？ SELECT OBJECT_NAME(i.OBJECT_ID) AS TableName, i.name AS TableIndexName FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat INNER JOIN sys.indexes i ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id WHERE phystat.avg_fragmentation_in_percent > 20 AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL ORDER BY phystat.avg_fragmentation_in_percent DESC 私はDBAではないので、上記のクエリで明らかな間違いを犯している可能性があります。または、役立つインデックスまたは統計があるかもしれません。たぶん、それはデータベースのサイズだけです（約140のテーブルで約20Gb）。 私が尋ねる理由は、夜中にメンテナンスのための非常に小さなウィンドウしかなく、これがほとんどの時間を占めているからです。

14 sql-server  index  query-performance  maintenance  dmv 

VARCHAR（20）列を持つ大きなテーブルがあり、それをVARCHAR（50）列になるように変更する必要があります。通常、この特定のテーブルでALTER TABLEを実行（TINYINTを追加）するのに約90〜120分かかります。そのため、データベースのユーザーに影響を与えないために、土曜日または日曜日の夜にしかできません。可能であれば、その前にこの変更を行いたいと思います。 列にもインデックスが付けられますが、列の長さを変更した後にインデックスを再構築する必要があるため、ALTER TABLEが遅くなると思われます。 Webアプリは、MySQLレプリケーション環境（26個のスレーブと1個のマスター）でセットアップされます。一度どこかで、1つの方法は最初に各スレーブでALTER TABLEを実行し（ユーザーへの影響を最小限に抑える）、次にマスターでこれを行うことを思い出しますが、それからALTER TABLEコマンドをスレーブに複製しようとしませんか？ 私の質問は次のとおりです。ユーザーの混乱を最小限に抑えてこのテーブルを変更する最良の方法は何ですか？ 編集：テーブルはInnoDBです。

14 mysql  replication  index  innodb  alter-table 

検索機能では、検索する必要があるすべてのテーブルのレコードを含むビューを使用しています。ビューには、ほぼ2000万件のレコードがあります。このビューに対する検索には時間がかかりすぎています。 このビューのパフォーマンスを改善するためにどこを調べるべきですか？ ビューの大まかな定義は次のとおりです。13のテーブルと約30のフィールドが含まれます。 CREATE VIEW [dbo].[v_AllForSearch] AS SELECT FT.firstField AS [firstField] , FT.fld_primary AS [fld_primary] , FT.fld_thirdField AS [thirdField] , FT.fld_fourthField AS [fourthField] , ISNULL(ST.[fld_firstSearchField],'') AS [firstSearchField] , ISNULL(TT.[fld_thirdSearch],'') AS thirdSearch , ISNULL(TT.[fld_fourthSearch],'')AS fourthSearch , ISNULL(TT.[fld_fifthSearch],'')AS fifthSearch , ISNULL(FRT.[fld_sixthSearch],'') As [sixthSearch] , ISNULL(FRT.[fld_seventhSearch],'') AS [seventhSearch] , ISNULL(FRT.[fld_eightSearch],'')AS [eightSearch] , ISNULL(FIT.[fld_nineSearch],'') …

14 sql-server  index  optimization  view 

いくつかの仮定をしてみましょう。 次のような表があります。 a | b ---+--- a | -1 a | 17 ... a | 21 c | 17 c | -3 ... c | 22 私のセットに関する事実： テーブル全体のサイズは〜10 10行です。 私は値で〜100kの行を持ってa列内のa他の値（例えばについても同様、c）。 これは、列 'a'に〜100k個の異なる値があることを意味します。 私のクエリのほとんどは、aの特定の値のすべてまたはほとんどの値を読み取りますselect sum(b) from t where a = 'c'。 テーブルは、連続した値が物理的に近くなるように記述されます（順番に記述されているかCLUSTER、そのテーブルと列で使用されていると仮定しますa）。 テーブルが更新されることはめったにありません。読み取り速度のみが重要です。 テーブルは比較的狭い（タプルごとに〜25バイト、+ 23バイトのオーバーヘッドなど）。 問題は、どのようなインデックスを使用する必要があるかということです。私の理解は： BTreeここでの私の問題は、BTreeインデックスが重複する値を格納することを知っている限り、巨大になることです（テーブルが物理的にソートされていると想定できないため、必要です）。BTreeが巨大な場合、インデックスとインデックスが指すテーブルの部分の両方を読み取る必要があります。（fillfactor = 100インデックスのサイズを少し小さくするために使用できます。） BRIN私の理解では、役に立たないページを読むことを犠牲にして、ここに小さなインデックスを作成できるということです。小さな値を使用pages_per_rangeすると、インデックスが大きくなり（インデックス全体を読み取る必要があるためBRINで問題になります）、大きな値を使用pages_per_rangeすると、多くの無駄なページを読み取ることになります。pages_per_rangeそれらのトレードオフを考慮に入れた優れた価値を見つけるための魔法の公式はありますか？ GIN …

14 postgresql  index  query-performance  clustered-index  postgresql-9.6