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

SQL-Serverで主に使用されるインデックスの一種で、テーブルのデータをインデックスに揃えます。

1
SQL Server-クラスター化インデックスを使用する場合のデータページの保存方法
最近、クラスター化インデックスのデータページが連続して格納されていないことを聞きました。これは本当ですか？ おそらく、データページは通常、規則のいくつかの例外を除いて連続して格納されていますか？または、間違っていると聞き、データページが常に連続して保存されている可能性があります。 どうもありがとう。
3
SQL Server 2012でのPK GUIDのインデックス作成
私の開発者は、ほとんどすべてのテーブルでGUIDをPKとして使用するようにアプリケーションを設定しており、デフォルトでSQL ServerはこれらのPKでクラスター化インデックスを設定しています。 システムは比較的新しく、最大のテーブルは100万行を超えていますが、インデックス作成を検討しており、近い将来必要に応じて迅速にスケーリングできるようにしたいと考えています。 したがって、私の最初の傾向は、クラスター化インデックスを、DateTimeのbigint表現である作成済みフィールドに移動することでした。ただし、CXを一意にできる唯一の方法は、このCXにGUID列を含めることです。ただし、最初に作成されます。 これにより、クラスタリングキーの幅が広がりすぎて、書き込みのパフォーマンスが向上しますか？読み取りも重要ですが、書き込みはおそらくこの時点で大きな懸念事項です。
6
非常に大きな主キーインデックスを再構築する
AzureでホストされているSQLデータベースがあります。問題は、サイズが制御不能になっていることです。主キーのクラスター化インデックスで最大99％の断片化が見られます。 他のすべてのインデックスをonline=onオプションで再構築できますが、パフォーマンスには影響しません。PKクラスター化インデックスの1つのサイズが200GBを超えているため、この1つでREBUILD...WITH (ONLINE=ON)はロックが発生します。 すべてのタイムゾーンのユーザーがサイトにアクセスしているため、オフラインでインデックスを再構築できる時間を見つけることができません。 サイトでダウンタイムを発生させずに大きなインデックスを再構築するための最良の戦略は何ですか？ 断片化は99％なので、再編成しても効果がないと思います。問題は、オンラインでもテーブルがロックされることです。主な問題は、インデックスが200GBを超えることです。主キーは整数です。
2
インデックス付きビューが一意でないクラスター化インデックスを許可しないのはなぜですか？
インデックス付きビューを使用して、最もよく使用されるいくつかのビューのパフォーマンスを向上させることを検討してきました。 ただし、インデックス付きビューは、一意ではないクラスター化インデックスをサポートしていません。これは、データベース構造の残りの部分によって設定された優先順位に少し影響します。 たとえば、ここにいくつかのテーブルの簡略化したバージョンがあります。 -Groups- Group ID GroupName -Users- UserKey UserName FullName GroupID インデックスは、Groups.GroupID（非クラスター化）およびUsers.GroupID（クラスター化）にあります。クラスター化されたキーは、最も一般的には特定のグループの一連のユーザーが取得されるため、UsersテーブルのGroupIDにあります。当然、グループごとに複数のユーザーがいるため、このクラスター化インデックスは一意ではありません。 このため、この例のようにビューにインデックスを付けるときに、この優先順位に従う方法が少し不確かになります。これは、一意でないクラスター化インデックスを持つことができないためです。 ConsumableID ConsumableVariantID AllowThresholdOverwrite FullPath GroupID ManufacturerID Type ModelID 101 29 1 0.1.2.4. 4 3 3 2 実際には、常に一意であるこのビューの唯一の値はConsumableID列です。そのため、インデックスを配置する場所についてほとんど選択肢がありません。 通常のテーブルで許可されているのに、ビューが一意でないクラスター化インデックスを許可しないのはなぜですか？
2
クラスター化インデックスの選択-PKまたはFK？
私が持っているSQL Serverの2014台をその次のようになります。 OrderId int not null IDENTITY --this is the primary key column OrderDate datetime2 not null CustomerId int not null Description nvarchar(255) null 私のチームの一部の人々は、クラスター化インデックスをオンOrderIdにすることを提案しましたが、次の理由から、CustomerId+のOrderId方が適切な選択だと思います。 ほとんどすべてのクエリはWHERE CustomerId = @param、ではなく、OrderId CustomerIdはCustomerテーブルへの外部キーなので、CustomerId結合を高速化する必要があるクラスタ化インデックスを持つ 一方でCustomerId一意ではない、追加の持つOrderIdインデックスで指定した列は、（我々が使用できる一意性を保証するUNIQUEものを2列にクラスタ化インデックスを作成するときに一意性を持っていないのオーバーヘッドを回避するために、キーワードを） データが挿入されると、CustomerIdそしてOrderId決して変更、これらの行は、最初の書き込みの後に動き回ることはないので。 データアクセスは、デフォルトですべての列を要求するORMを介して行われるため、に基づくクエリが着信CustomerIdすると、クラスター化インデックスは追加の作業なしですべての列を提供できます。 んCustomerIdとOrderId最良の選択肢のようなアプローチの音は、上記に与えられましたか？それとも、OrderIdそれ自体が一意性を保証する単一の列であるため、それ自体が優れていますか？ 現在、テーブルにはにクラスター化インデックスがOrderIdあり、非クラスター化インデックスがにありますが、CustomerIdカバーしていません。そのため、ORMを使用しており、すべての列が要求されているため、それらを取得するのは追加の作業です。したがって、この投稿では、CIを改善してパフォーマンスを向上させることを検討しています。 DBでのアクティビティは、約85％が読み取り、15％が書き込みです。
2
DATALENGTHの合計がsys.allocation_unitsのテーブルサイズと一致しません
DATALENGTH()テーブル内のすべてのレコードのすべてのフィールドを合計すると、テーブルの合計サイズが得られるという印象を受けました。私は間違っていますか？ SELECT SUM(DATALENGTH(Field1)) + SUM(DATALENGTH(Field2)) + SUM(DATALENGTH(Field3)) TotalSizeInBytes FROM SomeTable WHERE X, Y, and Z are true 以下のクエリを使用して（オンラインから取得してテーブルサイズ、クラスター化インデックスのみを取得し、NCインデックスは含まない）、データベース内の特定のテーブルのサイズを取得しました。請求のために（部門に使用するスペースの量に応じて部門に請求します）、この表で各部門が使用したスペースの量を把握する必要があります。テーブル内の各グループを識別するクエリがあります。各グループがどれだけのスペースを使用しているかを知る必要があります。 1行あたりのスペースVARCHAR(MAX)は、テーブル内のフィールドが原因で大きく変動する可能性があるため、平均サイズ*部門の行の比率を取得することはできません。DATALENGTH()上記のアプローチを使用すると、以下のクエリで使用される合計スペースの85％しか取得できません。考え？ SELECT s.Name AS SchemaName, t.NAME AS TableName, p.rows AS RowCounts, (SUM(a.total_pages) * 8)/1024 AS TotalSpaceMB, (SUM(a.used_pages) * 8)/1024 AS UsedSpaceMB, ((SUM(a.total_pages) - SUM(a.used_pages)) * 8)/1024 AS UnusedSpaceMB FROM sys.tables t with …
1
非エンタープライズ版とパフォーマンスのnoexpandヒント
パフォーマンスを上げるには、インデックス付きビューを使用する必要があります。この比較表からわかるように、Standard Editionはインデックス付きビューをサポートしていません。しかしBOLは言う： インデックス付きビューは、SQL Serverのどのエディションでも作成できます。SQL Server Enterpriseでは、クエリオプティマイザーは自動的にインデックス付きビューを考慮します。他のすべてのエディションでインデックス付きビューを使用するには、NOEXPANDテーブルヒントを使用する必要があります。 それでうまくいくでしょう（私はパフォーマンスについて話している） select * from dbo.OrderTotals with (noexpand, index=IXCU_OrderTotals) SQL Server Standardエディションと同様に select * from dbo.OrderTotals エンタープライズ版では？ ビューのコードは次のとおりです。 CREATE VIEW dbo.OrderTotals WITH SCHEMABINDING AS select OrderId = r.OrderId , TotalQty = SUM(r.Quantity) , TotalGrossConsid = SUM(r.Price * r.Quantity) , XCount = COUNT_BIG(*) from dbo.Order r …
2
クラスター化インデックスを無効にすると、テーブルにアクセスできなくなるのはなぜですか？
インデックスが無効になると、定義はシステムカタログに残りますが、使用されなくなります。SQL Serverはインデックスを維持せず（テーブルのデータが変更されるため）、インデックスを使用してクエリを満たすことはできません。場合はクラスタ化インデックスが無効になっている、テーブル全体がアクセスできなくなります。 Bツリーを破棄してテーブルから直接データにアクセスできないのはなぜですか？（おそらくテーブルを行ごとにスキャンすることにより）データに完全にアクセス不能にするよりも適切でしょうか？ それは純粋に理論的な質問です-私は実際にはそうしません。それはシナリオでも、やることでもありません。なぜそうなるのかを知りたいのですが、内部的な問題だと考えてください。
2
クラスタ化インデックスの作成がテーブルの作成に失敗する
次のスクリプトを実行するとエラーが発生します。 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サーバーを除くすべてのサーバーで機能するため、これは奇妙です。私たちが行った修正は、テーブル作成ステートメントの外でクラスター化インデックスを作成することですが、誰かが以前にこの問題に遭遇したことがあれば、興味がありますか？
3
クラスタ化インデックスで再構築しますが、なぜデータサイズが縮小するのですか？
約15 GBのデータが含まれ、データサイズが5 GBに縮小されたテーブルのクラスター化インデックスで再構築を行った場合、これはどのように行われますか？どのような「データ」が削除されますか？ データサイズは、DBCC sp_spaceusedの "data"列を意味します クラスタ化インデックスで再構築する前： name rows reserved data index_size unused LEDGERJOURNALTRANS 43583730 39169656 KB 15857960 KB 22916496 KB 395200 KB クラスタ化インデックスで再構築した後： name rows reserved data index_size unused LEDGERJOURNALTRANS 43583730 29076736 KB 5867048 KB 22880144 KB 329544 KB 再構築のためのTSQL： USE [DAX5TEST] GO ALTER INDEX [I_212RECID] ON [dbo].[LEDGERJOURNALTRANS] REBUILD …
1
INSTEAD OF UPDATEトリガーを持つテーブルに対するUPDATEが、クラスター化インデックスの更新だけでなく、クラスター化インデックスの挿入も行うように見えるのはなぜですか？
非常に単純な例から始めましょう。2つのテーブルが同じスキーマで、PKでクラスター化されていますが、そのうちの1つにINSTEAD OF UPDATEトリガーがあります。 CREATE TABLE Standard ( PK UNIQUEIDENTIFIER PRIMARY KEY CLUSTERED, V INT NOT NULL ) GO CREATE TABLE InsteadOf ( PK UNIQUEIDENTIFIER PRIMARY KEY CLUSTERED, V INT NOT NULL ) GO INSERT Standard (PK, V) VALUES ('1E58B555-B073-471E-B576-4B09C8E18976', 0) INSERT InsteadOf (PK, V) VALUES ('1E58B555-B073-471E-B576-4B09C8E18976', 0) GO CREATE TRIGGER …
2
クラスタ化インデックスが使用されている場合、「行外」フィールドは読み取られますか？
VARCHAR(MAX)/NVARCHAR(MAX)列を使用するとデータが格納されることを知っています。out of the rowデータ行には、「大きな値」が格納されている別の場所へのポインターがあります。 次の質問があります。 各フィールドは格納されout of the rowていmaxますか、それとも1つだけですか？ clustered indexレコード全体を読み取るためにテーブルのを使用している場合、行から格納されているフィールドも読み取られますか？ VARCHAR（MAX）またはNVARCHAR（MAX）は「大きな値の型」と見なされます。大きな値型は通常「行外」に格納されます。つまり...
4
SQL Serverインデックスを意図的に断片化するにはどうすればよいですか？
私が持っているSQL Server 2017テストデータベースで意図的に不良インデックス条件を作成したいのですが、これらのメンテナンススクリプトをよりよく理解するためですか？SQL Serverのインデックスと統計のメンテナンス インデックスの整合性を損なったり、インデックスの断片化を増やしたりする高速/自動の方法はありますか？これを達成するために私が調べることができる有用なリソースを知っていますか？
3
非クラスター化インデックスは行の順序について何か保証しますか？
私は、order byなしのselectステートメントを実行するときに、テーブルの行が挿入された順序になるようにしたいと考えている開発者がいます。開発者は、クラスター化インデックスから非クラスター化インデックスへの変更を提案しました。 インデックスをクラスター化から非クラスター化に変更することで、テーブルに行が表示される順序について何か保証はありますか？ この質問は主に私の好奇心です。代わりにID列を使用することをお勧めしますが、このリクエストは私に考えさせられました。タイムスタンプを使用できますが、行を同時に挿入できる可能性があります。 よろしくお願いします。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.