J'ai une table avec 490 M lignes et 55 Go d'espace table, donc environ 167 octets par ligne. Le tableau comporte trois colonnes: a VARCHAR(100)
, a DATETIME2(0)
et a SMALLINT
. La longueur moyenne du texte dans le VARCHAR
champ est d'environ 21,5, donc les données brutes doivent être d'environ 32 octets par ligne: 22 + 2 pour le VARCHAR
, 6 pour le DATETIME2
et 2 pour l'entier 16 bits.
Notez que l'espace ci-dessus est uniquement des données, pas des indices. J'utilise la valeur indiquée sous Propriétés | Stockage | Général | Espace de données.
Bien sûr, il doit y avoir une surcharge, mais 135 octets par ligne semble beaucoup, surtout pour une grande table. Pourquoi est-ce possible? Quelqu'un d'autre a-t-il vu des multiplicateurs similaires? Quels facteurs peuvent influencer la quantité d'espace supplémentaire nécessaire?
À titre de comparaison, j'ai essayé de créer une table avec deux INT
champs et 1 M lignes. L'espace de données requis était de 16,4 Mo: 17 octets par ligne, contre 8 octets de données brutes. Une autre table de test avec un INT
et un VARCHAR(100)
rempli avec le même texte que le vrai tableau utilise 39 octets par ligne (44 K lignes), où j'attendrais 28 plus un peu.
Ainsi, la table de production a considérablement plus de frais généraux. Est-ce parce que c'est plus grand? Je m'attendrais à ce que la taille des index soit à peu près N * log (N), mais je ne vois pas pourquoi l'espace requis pour que les données réelles soient non linéaires.
Merci d'avance pour tous les pointeurs!
ÉDITER:
Tous les champs répertoriés sont NOT NULL
. La vraie table a un PK en cluster sur le VARCHAR
terrain et le DATETIME2
champ, dans cet ordre. Pour les deux tests, le premier INT
était le PK (groupé).
Si cela importe: le tableau est un enregistrement des résultats de ping. Les champs sont URL, date / heure de ping et latence en millisecondes. Les données sont constamment ajoutées et jamais mises à jour, mais les données sont supprimées périodiquement pour les réduire à quelques enregistrements par heure et par URL.
ÉDITER:
Une réponse très intéressante ici suggère que, pour un index avec beaucoup de lecture et d'écriture, la reconstruction peut ne pas être bénéfique. Dans mon cas, l'espace consommé est un problème, mais si les performances d'écriture sont plus importantes, on peut être mieux avec des indices flasques.