Comment estimer la taille des index SQL Server?

Question

Alors que l’estimation de la taille des lignes droites et des tables est un calcul assez simple, nous trouvons difficile de deviner combien d’espace chaque index occupera (pour une taille de table donnée). Quels domaines pouvons-nous apprendre à calculer une meilleure estimation et un meilleur taux de croissance pour les indices?

Answer 1

Une feuille d’index a un préambule identifiant la page de données (7 octets plus quelques informations de répertoire pour les colonnes de longueur variable, le cas échéant) plus une copie de la ou des valeurs de clé qui auront la même taille que les données de la table pour celles-ci. colonnes. Il y en a un pour chaque ligne du tableau. Les niveaux les plus élevés de l'indice sont beaucoup plus petits, généralement moins de 1% des feuilles, sauf si vous indexez une clé très large.

Le facteur de remplissage laisse un espace libre afin que les mises à jour et les insertions ne génèrent pas un trafic excessif avec le fractionnement des feuilles.

EDIT: Ce lien MSDN décrit les structures au niveau des pages, bien que le format des différentes lignes d'index soit un peu clair. Cette présentation va dans le format physique des entrées de journal de disque et des pages de données dans une certaine mesure. Celui-ci contient plus de détails et l'index structures de données. Les colonnes numériques et de longueur fixe ont la taille indiquée sur la boîte; vous auriez à estimer la taille moyenne des colonnes varchar.

À titre de référence, certains documents sur le format de bloc d’Oracle se trouvent ici et Ici .

Answer 2

lorsque cela est possible, je prends généralement 1000 enregistrements de la table d'origine, les insérer dans ma propre table, et avec le script ci-dessous, j'ai un échantillon pour jouer avec.

Ok, ce n’est pas précis, mais peut me donner un point de départ.

--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
--========================================================================================