Implémentation de la compression de ligne
S’applique à : 
SQL Server Base de données Azure SQL Azure SQL Managed Instance
Cet article récapitule la manière dont le moteur de base de données implémente la compression de ligne. Elle fournit des informations de base qui vous aideront à planifier l'espace de stockage dont vous avez besoin pour vos données.
L'activation de la compression modifie uniquement le format de stockage physique des données qui sont associées à un type de données, mais pas leur syntaxe ni leur sémantique. Aucune modification de l'application n'est requise lorsqu'une ou plusieurs tables sont activées pour la compression. Le nouveau format de stockage des enregistrements propose les améliorations suivantes :
Il réduit la charge mémoire des métadonnées qui est associée à l'enregistrement. Ces métadonnées sont des informations sur les colonnes, leur longueur et leur décalage. Dans certains cas, la charge mémoire des métadonnées peut être plus importante qu'avec l'ancien format de stockage.
Il utilise le format de stockage de longueur variable pour les types de données numériques (par exemple integer, decimalet float) et les types reposant sur le type numérique (par exemple datetime et money).
Il stocke les chaînes de caractères de longueur fixe en utilisant le format de longueur variable, mais sans stocker les caractères blancs.
Remarque
Les valeurs NULL et 0 de tous les types de données sont optimisées et n'occupent aucun octet.
Conséquences de la compression de ligne sur le stockage
La table suivante décrit comment la compression de ligne affecte les types existants dans SQL Server et base de données Azure SQL. Elle n'indique pas les économies qui peuvent être réalisées en utilisant la compression de page.
| Type de données | Le stockage est-il affecté ? | Description |
|---|---|---|
| tinyint | Non | 1 octet est la quantité de stockage minimale nécessaire. |
| smallint | Oui | Si la valeur rentre dans 1 octet, 1 seul octet est utilisé. |
| int | Oui | Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée dans 1 octet, le stockage n'occupe qu'un seul octet. |
| bigint | Oui | Utilise uniquement les octets nécessaires. Par exemple, si une valeur peut être stockée dans 1 octet, le stockage n'occupe qu'un seul octet. |
| decimal | Oui | Utilise uniquement les octets nécessaires, quelle que soit la précision spécifiée. Par exemple, si une valeur peut être stockée dans 3 octets, le stockage n’occupe que 3 octets. L’encombrement du stockage est exactement le même que le format de stockage vardecimal. |
| Numérique | Oui | Utilise uniquement les octets nécessaires, quelle que soit la précision spécifiée. Par exemple, si une valeur peut être stockée dans 3 octets, le stockage n’occupe que 3 octets. L’encombrement du stockage est exactement le même que le format de stockage vardecimal. |
| bit | Oui | La charge mémoire des métadonnées porte cette valeur à 4 bits. |
| smallmoney | Oui | Utilise la représentation des données de type entier sur un entier de 4 octets. La valeur monétaire est multipliée par 10 000 et la valeur entière résultante est stockée en supprimant tous les chiffres après la virgule. L'optimisation du stockage de ce type de données est semblable à celle des types de données entiers. |
| money | Oui | Utilise la représentation des données de type entier sur un entier de 8 octets. La valeur monétaire est multipliée par 10 000 et la valeur entière résultante est stockée en supprimant tous les chiffres après la virgule. Ce type a une plus grande plage que smallmoney. L'optimisation du stockage de ce type de données est semblable à celle des types de données entiers. |
| float | Oui | Les octets les moins significatifs comprenant des zéros ne sont pas stockés. La compressionfloat est principalement applicable aux valeurs non fractionnaires de la mantisse. |
| real | Oui | Les octets les moins significatifs comprenant des zéros ne sont pas stockés. La compressionreal est principalement applicable aux valeurs non fractionnaires de la mantisse. |
| smalldatetime | Non | Utilise la représentation des données de type entier sur deux entiers de 2 octets et correspond au nombre de jours écoulés depuis 1900-01-01. Il n’y a pas d’avantage à la compression de ligne pour la partie date de smalldatetime.L'heure est le nombre de minutes depuis minuit. Les valeurs d'heure situées légèrement après 16h00 commencent à utiliser le deuxième octet. Si un smalldatetime est utilisé uniquement pour représenter une date (ce qui est souvent le cas), l’heure est 0.0. La compression permet d'économiser 2 octets en stockant l'heure dans le format d'octet le plus significatif pour la compression de ligne. |
| datetime | Oui | Utilise la représentation des données de type entier sur deux entiers de 4 octets. La valeur entière représente le nombre de jours depuis la date de base du 1900-01-01. Les 2 premiers octets peuvent représenter jusqu'à l'année 2079. La compression permet toujours d'économiser 2 octets jusqu'à cette date. Chaque valeur entière représente 3,33 millisecondes. La compression épuise les 2 premiers octets dans les cinq premières minutes et a besoin du quatrième octet après 16h00. La compression permet donc d'économiser uniquement 1 octet après 16h00. Lorsque datetime est compressé comme tout autre entier, la compression permet d'économiser 2 octets dans la date. |
| date | Non | Utilise la représentation des données de type entier sur 3 octets. Ceci représente la date à compter du 0001-01-01. Pour les dates contemporaines, la compression de ligne utilise les 3 octets. Aucune économie n'est réalisée. |
| time | Non | Utilise la représentation des données de type entier sur 3 à 6 octets. Plusieurs précisions démarrent par un chiffre compris entre 0 et 9 et peuvent occuper entre 3 et 6 octets. L'espace compressé est utilisé comme suit : Précision = 0. Octets = 3. Chaque valeur entière représente une seconde. La compression peut représenter l'heure jusqu'à 6h00 sur 2 octets, ce qui permet d'économiser potentiellement 1 octet. Précision = 1. Octets = 3. Chaque valeur entière représente 1/10 seconde. La compression utilise le troisième octet avant 2h00. De petites économies sont ainsi réalisées. Précision = 2. Octets = 3. Semblable au cas précédent, la réalisation d'économies est peu probable. Précision = 3. Octets = 4. Dans la mesure où les 3 premiers octets sont occupés dès 5h00, peu d'économies sont réalisées par le biais de cette option. Précision = 4. Octets = 4. Les trois premiers octets sont occupés dans les 27 premières secondes. Aucune économie n'est attendue. Précision = 5, Octets = 5. Le cinquième octet sera utilisé après midi. Précision = 6 et 7, Octets = 5. Ne réalise pas d'économies. Précision = 8, Octets = 6. Le sixième octet sera utilisé après 3h00. Il n'y a aucune modification dans le stockage pour la compression de ligne. Globalement, peu d'économies peuvent être attendues de la compression du type de données time . |
| datetime2 | Oui | Utilise la représentation des données de type entier sur 6 à 9 octets. Les 4 premiers octets représentent la date. Les octets occupés par la date dépendent de la précision de l'heure spécifiée. La valeur entière représente le nombre de jours depuis le 0001-01-01, avec une date limite située au 31/12/9999. La représentation d'une date de l'année 2005 occupe 3 octets.Aucune économie n'est réalisée sur les heures car 2 à 4 octets sont nécessaires pour différentes précisions d'heure. Par conséquent, pour une précision de l'heure à la seconde, la compression utilise 2 octets pour l'heure et occupe le deuxième octet après 255 secondes. |
| datetimeoffset | Oui | Similaire à datetime2, mais avec 2 octets de fuseau horaire au format (HH:mm).Comme datetime2, la compression peut permettre d'économiser 2 octets. Pour les valeurs de fuseau horaire, la valeur mm peut être 0 dans la plupart des cas. Par conséquent, la compression peut permettre d'économiser 1 octet.Il n'y a aucune modification dans le stockage pour la compression de ligne. |
| char | Oui | Les caractères de remplissage à droite sont supprimés. Notez que le moteur de base de données insère le même caractère tampon quel que soit le classement utilisé. |
| varchar | Non | Aucun effet. |
| texte | Non | Aucun effet. |
| nchar | Oui 1 | Les caractères de remplissage à droite sont supprimés. Notez que le moteur de base de données insère le même caractère tampon quel que soit le classement utilisé. |
| nvarchar | Non 1 | Aucun effet. |
| ntext | Non | Aucun effet. |
| binary | Oui | Les zéros de droite sont supprimés. |
| varbinary | Non | Aucun effet. |
| image | Non | Aucun effet. |
| cursor | Non | Aucun effet. |
| timestamp / rowversion | Oui | Utilise la représentation des données de type entier sur 8 octets. Un compteur d'horodatage, dont la valeur commence à 0, est maintenu pour chaque base de données. Il peut être compressé comme toute autre valeur entière. |
| sql_variant | Non | Aucun effet. |
| uniqueidentifier | Non | Aucun effet. |
| table | Non | Aucun effet. |
| xml | Non2 | Aucun effet. |
| Types définis par l'utilisateur | Non | Représentés en interne sous la forme varbinary. |
| FILESTREAM | Non | Représentés en interne sous la forme varbinary. |
1 La compression Unicode prend en charge les types de données de longueur fixe nchar et nvarchar. Les valeurs de données stockées hors ligne ou dans des colonnes nvarchar(max) ne sont pas compressées. La compression Unicode n’est pas prise en charge pour les données nvarchar(max), même si celles-ci sont stockées dans des lignes.
2 Les données hors ligne ne sont pas compressées lorsque la compression des données est activée. Par exemple, un enregistrement XML de plus de 8 060 octets utilise des pages hors ligne, qui ne sont pas compressées.