L'ordre logique des colonnes dans une table a-t-il un impact sur leur ordre physique au niveau de la couche de stockage? Oui.
Que ce soit important ou non est une question différente à laquelle je ne peux pas (encore) répondre.
D'une manière similaire à celle décrite dans l'article fréquemment lié de Paul Randal sur l' anatomie d'un enregistrement , examinons un simple tableau à deux colonnes avec DBCC IND:
SET STATISTICS IO OFF;
SET STATISTICS TIME OFF;
USE master;
GO
IF DATABASEPROPERTY (N'RowStructure', 'Version') > 0 DROP DATABASE RowStructure;
GO
CREATE DATABASE RowStructure;
GO
USE RowStructure;
GO
CREATE TABLE FixedLengthOrder
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
, c3 CHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
);
GO
INSERT FixedLengthOrder DEFAULT VALUES;
GO
DBCC IND ('RowStructure', 'FixedLengthOrder', 1);
GO
La sortie ci-dessus montre que nous devons examiner la page 89:
DBCC TRACEON (3604);
GO
DBCC PAGE ('RowStructure', 1, 89, 3);
GO
Dans la sortie de DBCC PAGE, nous voyons c1 bourré avec le caractère 'A' avant le 'B' de c2:
Memory Dump @0x000000000D25A060
0000000000000000: 10001c00 01000000 41414141 41414141 †........AAAAAAAA
0000000000000010: 41414242 42424242 42424242 030000††††AABBBBBBBBBB...
Et juste parce que, ouvrons RowStructure.mdf
un éditeur hexadécimal et confirmons que la chaîne 'A' précède la chaîne 'B':
Répétez maintenant le test en inversant l’ordre des chaînes en plaçant les caractères "B" en c1 et les caractères "A" en c2:
CREATE TABLE FixedLengthOrder
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
, c3 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
);
GO
Cette fois, notre sortie DBCC PAGE est différente et la chaîne 'B' apparaît en premier:
Memory Dump @0x000000000FC2A060
0000000000000000: 10001c00 01000000 42424242 42424242 †........BBBBBBBB
0000000000000010: 42424141 41414141 41414141 030000††††BBAAAAAAAAAA...
Encore une fois, juste pour rire, vérifions le vidage hexadécimal du fichier de données:
Comme l'explique Anatomie d'un enregistrement , les colonnes de longueur fixe et variable d'un enregistrement sont stockées dans des blocs distincts. L'entrelacement logique de types de colonnes fixes et variables n'a aucune incidence sur l'enregistrement physique. Cependant, dans chaque bloc, l'ordre de vos colonnes correspond à l'ordre des octets dans le fichier de données.
CREATE TABLE FixedAndVariableColumns
(
c1 INT IDENTITY(1,1) PRIMARY KEY CLUSTERED
, c2 CHAR(10) DEFAULT REPLICATE('A', 10) NOT NULL
, c3 VARCHAR(10) DEFAULT REPLICATE('B', 10) NOT NULL
, c4 CHAR(10) DEFAULT REPLICATE('C', 10) NOT NULL
, c5 VARCHAR(10) DEFAULT REPLICATE('D', 10) NOT NULL
, c6 CHAR(10) DEFAULT REPLICATE('E', 10) NOT NULL
);
GO
Memory Dump @0x000000000E07C060
0000000000000000: 30002600 01000000 41414141 41414141 †0.&.....AAAAAAAA
0000000000000010: 41414343 43434343 43434343 45454545 †AACCCCCCCCCCEEEE
0000000000000020: 45454545 45450600 00020039 00430042 †EEEEEE.....9.C.B
0000000000000030: 42424242 42424242 42444444 44444444 †BBBBBBBBBDDDDDDD
0000000000000040: 444444†††††††††††††††††††††††††††††††DDD
Voir également:
L'ordre des colonnes n'a pas d'importance… en général, mais - CELA DÉPEND!
CREATE TABLE
instruction (sauf que les colonnes de clé CI venaient en premier dans la section). Bien que l'ordre des colonnes puisse changer si lesALTER COLUMN
types de données / la longueur des colonnes sont modifiés . Le seul cas mineur auquel il est important de penser est que les colonnes à la fin de la section de longueur variable avec une chaîne vide ou NULL ne prennent aucun espace dans le tableau de décalage de colonne (démontré par Kalen Delaney dans le livre internals 2008)