Utilisation d'une taille de colonne beaucoup plus grande que nécessaire


16

Je crée une base de données SQL Server avec quelqu'un d'autre. L'un des tableaux est petit (6 lignes) avec des données qui resteront probablement constantes. Il existe une possibilité à distance qu'une nouvelle ligne soit ajoutée. Le tableau ressemble à ceci:

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

Je regarde la longueur des caractères de cette namecolonne, et je pense que ses valeurs ne seront probablement jamais supérieures à, disons, 32 caractères, peut-être même pas supérieures à 24. Y a-t-il un avantage à changer cette colonne en, par exemple varchar(32),?

De plus, y a-t-il un avantage à conserver les tailles de colonne par défaut à des multiples de 4, 8, 32, etc.?

Réponses:


15

SQL Server utilise des longueurs de colonne lors de l'allocation de mémoire pour le traitement des requêtes. Donc, oui, en bref, vous devez toujours dimensionner les colonnes de manière appropriée pour les données.

Les allocations de mémoire sont basées sur le nombre de lignes renvoyées par la requête multiplié par la moitié de la longueur déclarée de la colonne.

Cela dit, dans ce cas où vous avez 6 lignes, vous ne voulez probablement pas trop optimiser prématurément. Sauf si vous JOIGNEZ ce tableau à un autre avec des millions de lignes, il n'y aura pas de différence énorme entre un varchar (24) et un varchar (32), ou même un varchar (128).

Votre deuxième question concerne l'alignement des longueurs de colonne sur les multiples binaires. Ce n'est pas du tout nécessaire car SQL Server stocke toutes les données dans des pages de 8 Ko, quelle que soit la longueur de chaque colonne.


14

Avec 6 lignes, non, il n'y aura aucun avantage observable. Ce tableau entier tiendra sur une seule page, donc réduire l'espace potentiel maximal que vous utiliserez sur cette page tout en occupant cette page entière n'est vraiment pas différent dans tous les sens pratiques.

Sur les tables plus grandes, cependant, le dimensionnement à droite est crucial. La raison en est que les estimations de la mémoire seront basées sur l'hypothèse que chaque valeur sera remplie à 50%. Donc, si vous avez varchar (128), chaque valeur s'attendra à occuper 64 octets, quelles que soient les données réelles, donc les allocations de mémoire seront de 64b * nombre de lignes. Si toutes les valeurs seront de 32 caractères ou moins, en faire un varchar (64) ou même varchar (32) est probablement un meilleur choix. Si un grand pourcentage de valeurs est proche ou au maximum, vous pourriez même plaider pour que l'omble chevalier en élimine la volatilité.

Quant aux avantages d'avoir des longueurs de chaîne plafonnées à des puissances de 2, je ne pense pas que sur le matériel d'aujourd'hui, quiconque puisse démontrer des avantages évidents.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.