Чи логічне впорядкування стовпців у таблиці впливає на їх фізичний порядок на рівні зберігання? Так.
Це важливо чи ні - це інше питання, на яке я не можу відповісти (поки що).
Аналогічно тому, як описано у часто пов’язаній статті Пола Рандала про анатомію запису , давайте розглянемо просту таблицю з двома стовпцями з 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
Вихідний результат показує, що нам потрібно переглянути сторінку 89:
DBCC TRACEON (3604);
GO
DBCC PAGE ('RowStructure', 1, 89, 3);
GO
У висновку з DBCC PAGE ми бачимо c1, заповнений символом 'A' перед c2 'B':
Memory Dump @0x000000000D25A060
0000000000000000: 10001c00 01000000 41414141 41414141 †........AAAAAAAA
0000000000000010: 41414242 42424242 42424242 030000††††AABBBBBBBBBB...
І тільки тому, що дозволяє відкрити бюст RowStructure.mdfіз шестигранним редактором та підтвердити, що рядок "A" передує рядку "B":
Тепер повторіть тест, але поверніть порядок рядків, розмістивши символи 'B' у c1, а символи 'A' в 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
На цей раз наш вихід DBCC PAGE відрізняється, і рядок "B" з'являється першим:
Memory Dump @0x000000000FC2A060
0000000000000000: 10001c00 01000000 42424242 42424242 †........BBBBBBBB
0000000000000010: 42424141 41414141 41414141 030000††††BBAAAAAAAAAA...
Знову ж таки, лише для хихикань, давайте перевірити шістнадцятковий дамп файлу даних:
Як пояснює анатомія запису , стовпці фіксованої та змінної довжини запису зберігаються у різних блоках. Логічне переплетення фіксованих та змінних типів стовпців не стосується фізичного запису. Однак у кожному блоці порядок ваших стовпців відображає порядок байт у файлі даних.
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
Дивись також:
Порядок стовпців не має значення… загалом, але - ВІДЗВИТАЄ!
CREATE TABLEтвердженням (за винятком того, що ключові стовпці CI мають перше місце в розділі) Хоча порядок стовпців може змінюватися, якщоALTER COLUMNзмінюються типи даних / довжини стовпців. Єдиний незначний випадок, коли я маю на увазі те, що стовпці в кінці розділу змінної довжини з порожнім рядком або NULL взагалі не займають місця в масиві зміщення стовпців (продемонстровано Каленом Делані в книзі внутрішніх справ 2008 року)