直線の行とテーブルのサイズを見積もるのはかなり単純な計算ですが、各インデックスが（特定のテーブルサイズに対して）どのくらいのスペースを占めるかを推測するのは難しいと思います。インデックスのより良い見積もりと成長率を計算するために、どの分野を学ぶことができますか？
icelava
質問する
6399 次
2 に答える
6
インデックス リーフには、データ ページを識別するプリアンブル (7 バイトと、可変長列のディレクトリ情報がある場合) と、それらの列のテーブル データと同じサイズになるキー値のコピーがあります。テーブルの各行に 1 つあります。インデックスの上位レベルははるかに小さく、非常に広いキーをインデックス化している場合を除き、通常はリーフの 1% 未満です。
フィル ファクタは、更新と挿入によって過剰なリーフ分割トラフィックが生成されないように、ある程度の空き領域を残します。
編集:この MSDN リンクでは、ページ レベルの構造について説明していますが、個々のインデックス行の形式については少しわかりにくいです。 このプレゼンテーションでは、ディスク ログ エントリとデータ ページの物理フォーマットについてある程度説明します。 これはもう 1 つの詳細であり、インデックス データ構造が含まれています。数値および固定長の列は、ボックスに記載されているサイズです。varchar 列の平均サイズを見積もる必要があります。
于 2008-10-07T08:24:59.460 に答える
1
可能であれば、通常、元のテーブルから 1000 レコードを取得し、それらを自分のテーブルに挿入します。以下のスクリプトを使用して、サンプルを試してみます。
正確ではありませんが、出発点を教えてください。
--Find out the disk size of an index:
--USE [DB NAME HERE]
go
SELECT
OBJECT_NAME(I.OBJECT_ID) AS TableName,
I.name AS IndexName,
8 * SUM(AU.used_pages) AS 'Index size (KB)',
CAST(8 * SUM(AU.used_pages) / 1024.0 AS DECIMAL(18,2)) AS 'Index size (MB)'
FROM
sys.indexes I
JOIN sys.partitions P ON P.OBJECT_ID = I.OBJECT_ID AND P.index_id = I.index_id
JOIN sys.allocation_units AU ON AU.container_id = P.partition_id
--WHERE
-- OBJECT_NAME(I.OBJECT_ID) = '<TableName>'
GROUP BY
I.OBJECT_ID,
I.name
ORDER BY
TableName
--========================================================================================
--http://msdn.microsoft.com/en-us/library/fooec9de780-68fd-4551-b70b-2d3ab3709b3e.aspx
--I believe that keeping the GROUP BY
--is the best option in this case
--because of sys.allocation_units
--can have 4 types of data inside
--as below:
--type tinyint
--Type of allocation unit.
--0 = Dropped
--1 = In-row data (all data types, except LOB data types)
--2 = Large object (LOB) data (text, ntext, image, xml, large value types, and CLR user-defined types)
--3 = Row-overflow data
--marcelo miorelli 8-NOV-2013
--========================================================================================
于 2014-05-23T13:08:36.660 に答える