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

クラスター化された主キーを新しいファイルグループに移動するにはどうすればよいですか？私はすでに可能な「アルゴリズム」を見つけましたが、恐ろしく非効率的です： クラスター化されていないインデックス付きのドロップ（それらを再ソートして再構築する必要があります） クラスター化インデックスを削除します（テーブル全体を再ソートする必要があります） 新しい主キー制約を作成します（巨大なソート操作） すべての非クラスター化インデックスを作成する（並べ替えと書き込みが必要） より効率的な方法はありますか？これはひどく非効率的であり、弱いサーバーではテーブルのサイズが50GBであるため、時間がかかります。 これらすべてをスキップして、新しいファイルグループで再構築する方法はありませんか？データの並べ替えは必要ありません。

14 sql-server  index  sql-server-2012  filegroups 

次のような、720万タプルのテーブルがあります。 table public.methods column | type | attributes --------+-----------------------+---------------------------------------------------- id | integer | not null DEFAULT nextval('methodkey'::regclass) hash | character varying(32) | not null string | character varying | not null method | character varying | not null file | character varying | not null type | character varying | …

14 postgresql  performance  index  sorting  group-by 

デフォルトのFILL FACTORが20のデータベースがあるとします。データが挿入されるたびに、最大20％のページのみが作成されますか？ 私の理解では、データが挿入されると、ページ内のデータの約20％になります。ただし、データが更新されると、インデックスの20％以上に拡張され、データがいっぱいになってページ分割が生成されます。

14 sql-server  sql-server-2008-r2  index  fill-factor 

インデックスの膨張に悩まされているPostgreSQLでインデックスを再作成する必要があります。作成中にインデックスを使用できるようにする必要があるため、REINDEXを使用できません。新しい名前でインデックスを再作成してから、古いインデックスを削除します。インデックスを作成するために使用されたSQLステートメントを確認して、それをコピーする方法はありますか？

14 postgresql  index 

ページ圧縮（ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)）を使用してSQL Serverインデックスを再構築した後、（特定の断片化しきい値を超えた一部のメンテナンススクリプトで行われるように）その後の再構築では、データ圧縮を再度指定する必要がありますか？そうでなければ、インデックスは効果的に圧縮解除されますか？

13 sql-server  index  compression  data-pages 

次の表を作成しました。 CREATE TABLE dbo.TestStructure ( id INT NOT NULL, filler1 CHAR(36) NOT NULL, filler2 CHAR(216) NOT NULL ); 次に、クラスター化インデックスを作成しました。 CREATE CLUSTERED INDEX idx_cl_id ON dbo.TestStructure(id); 次に、各サイズが256バイトである30行（テーブル宣言に基づいて）を入力しました。 DECLARE @i AS int = 0; WHILE @i < 30 BEGIN SET @i = @i + 1; INSERT INTO dbo.TestStructure (id, filler1, filler2) VALUES …

13 sql-server  index  t-sql  data-pages 

次のように定義されたSQL Serverテーブルがあります CREATE TABLE [dbo].[Production_Detail] ( [Id] [bigint] NOT NULL DEFAULT (NEXT VALUE FOR [dbo].[Production_Detail_Seq]), [Meta_Data_ID] INT NOT NULL , [Production_Detail_Time] DATETIME NOT NULL, [Production_Detail_Time_Local] DATETIME NOT NULL, [Production_Detail_Value] FLOAT NULL, [IntegratedDM] BIT NOT NULL DEFAULT 0, [DailyIntegratedDM] BIT NOT NULL DEFAULT 0, [InsertedDate] DateTime NOT NULL, [ModifiedDate] DateTime NOT …

13 sql-server  sql-server-2012  index  delete  clustered-index 

私はPostgres 9.3.5を使用しており、データベースに大きなテーブルがあります。現在は2500万行以上あり、急速に大きくなる傾向があります。次のような簡単なクエリを使用して、特定の行（すべてunit_idのsに最新のもののみを含む）を選択しようとしていますunit_timestamp。 SELECT unit_id, max(unit_timestamp) AS latest_timestamp FROM all_units GROUP BY unit_id; インデックスがない場合、このクエリの実行には約35秒かかります。定義されたインデックス（CREATE INDEX partial_idx ON all_units (unit_id, unit_timestamp DESC);）を使用すると、クエリ時間は約（わずか）19秒に短縮されます。 クエリをさらに短い時間（ほんの数秒など）で実行できるようになるのではないかと考えています。その場合、クエリをさらに最適化するにはどのような手順を実行する必要がありますか。 テーブル構造のダンプは次のようになります。 CREATE TABLE "all_units" ( "unit_id" int4 NOT NULL, "unit_timestamp" timestamp(6) NOT NULL, "lon" float4, "lat" float4, "speed" float4, "status" varchar(255) COLLATE "default" ) ALTER TABLE "all_units" ADD PRIMARY …

13 postgresql  performance  index  query-performance 

テーブルがあります | base_schedule_line_items | CREATE TABLE base_schedule_line_items（ idint（10）unsigned NOT NULL AUTO_INCREMENT、 installmentint（10）unsigned NOT NULL、 on_datedate NOT NULL、 actual_datedate DEFAULT NULL、 payment_typeint（11）NOT NULL、 scheduled_principal_outstandingdecimal（65,0）NOT NULL、 scheduled_principal_duedecimal（65,0） NOT NULL、 scheduled_interest_outstandingdecimal（65,0）NOT NULL、 scheduled_interest_duedecimal（65,0）NOT NULL、 currencyint（11）NOT NULL、 updated_atdatetime NOT NULL DEFAULT '2013-01-06 14：29：16'、 created_atdatetime NOT NULL DEFAULT ' 2013-01-06 14：29：16 '、 loan_base_schedule_idint（10）unsigned NOT NULL、 …

13 mysql  index  index-tuning 

テーブルが与えられた場合： Column | Type id | integer latitude | numeric(9,6) longitude | numeric(9,6) speed | integer equipment_id | integer created_at | timestamp without time zone Indexes: "geoposition_records_pkey" PRIMARY KEY, btree (id) このテーブルには2000万件のレコードがありますが、比較的多くはありません。ただし、シーケンシャルスキャンが遅くなります。 max(created_at)それぞれの最後のレコード（）を取得するにはどうすればよいequipment_idですか？ 私はこのトピックの多くの回答を読んだいくつかのバリエーションを使用して、次の両方のクエリを試しました： select max(created_at),equipment_id from geoposition_records group by equipment_id; select distinct on (equipment_id) equipment_id,created_at from geoposition_records order by …

13 postgresql  performance  index  greatest-n-per-group 

違いは何ですかCREATE INDEXとCREATE STATISTICS私はそれぞれ使用すべきでは？

13 sql-server  index  statistics 

たとえば、2つのインデックスがある場合： CREATE INDEX IDX_1 ON MY_TABLE_1 (ITEM, DATE, LOCATION) COMPUTE STATISTICS; CREATE INDEX IDX_2 ON MY_TABLE_1 (DATE, LOCATION, ITEM) COMPUTE STATISTICS; これはIDX_2冗長になりますか？そうでない場合、列を宣言する順序を決定するにはどうすればよいですか？ 通常のクエリに合わせてインデックスを調整する必要がありますか？

13 oracle  index 

テーブル内で主キーを作成する方法は知っていますが、既存のインデックスを主キーにするにはどうすればよいですか？あるデータベースから別のデータベースに既存のテーブルをコピーしようとしています。テーブルを表示すると、下部のインデックスは次の形式になっています。 "my_index" PRIMARY KEY, btree (column1, column2) 私はインデックスを作成しました： CREATE INDEX my_index ON my_table (column1, column2) しかし、私はそれを主キーにする方法を知りません... 更新：サーバーのバージョンは8.3.3です

13 postgresql  index  primary-key 

DMVがページ数と行数に関する正確な情報を保持していないことは既知の事実です。ただし、統計を更新しても、なぜ更新されないのかわかりません。 私は監視ツールに取り組んでおり、各インデックスとデータのディスクサイズなどを知りたいと思っています。最終的には、適切なフィルファクターなどを見つけたいと思っています。 私の関数と古いsp_spaceusedで使用されるスペースは、スペース使用量で少し異なりますが、レコード数では異なりません。 私のセレクトに足りないものがありますか？ これはsp_spaceusedです（その後、数値をMBに変換します）。 sp_spaceused 'tblBOrderRelationship' go select 318008/1024.00 AS reserved, 140208/1024.00 AS data, 177048/1024.00 AS index_size, 752/1024.00 AS unused しかし、以下のselect \ codeのコードを実行すると、わずかに異なる数字が表示されます。 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED SELECT schema_name(t.schema_id) as SchemaName, t.NAME AS TableName, t.type_desc, t.is_ms_shipped, t.is_published, t.lob_data_space_id, t.filestream_data_space_id, t.is_replicated, t.has_replication_filter, t.is_merge_published, t.is_sync_tran_subscribed, --t.is_filetable, i.name as indexName, …

13 sql-server  index  disk-space  dmv 

多数の挿入を含むテーブルがあり、フィールド（uploaded_at）の1つをに設定していNULLます。次に、定期タスクがすべてのタプルを選択し、WHERE uploaded_at IS NULLそれらを処理して更新し、uploaded_at現在の日付に設定します。 テーブルにインデックスを付けるにはどうすればよいですか？ 次のような部分インデックスを使用する必要があることを理解しています。 CREATE INDEX foo ON table (uploaded_at) WHERE uploaded_at IS NULL またはそのようなsmth。しかし、常にフィールドにインデックスを付けることが正しい場合、私は少し混乱していますNULL。または、bツリーインデックスを使用することが正しい場合。ハッシュはより良いアイデアのように見えますが、廃止されており、ストリーミングホットスタンバイレプリケーションを介してレプリケートされません。どんなアドバイスも大歓迎です。 私は次のインデックスで少し実験しました： "foo_part" btree (uploaded_at) WHERE uploaded_at IS NULL "foo_part_id" btree (id) WHERE uploaded_at IS NULL クエリプランナーは常にfoo_partインデックスを選択するようです。explain analyseまた、foo_partインデックスの結果が若干良くなります： Index Scan using foo_part on t1 (cost=0.28..297.25 rows=4433 width=16) (actual time=0.025..3.649 rows=4351 loops=1) Index Cond: (uploaded_at …

13 postgresql  index  index-tuning  null