Thứ tự logic của các cột trong bảng có bất kỳ tác động nào đến trật tự vật lý của chúng ở lớp lưu trữ không? Vâng.
Cho dù nó có quan trọng hay không là một vấn đề khác mà tôi không thể trả lời (chưa).
Theo cách tương tự như được mô tả trong bài viết được liên kết thường xuyên từ Paul Randal về giải phẫu của một bản ghi , chúng ta hãy xem một bảng hai cột đơn giản với 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
Đầu ra ở trên cho thấy rằng chúng ta cần xem trang 89:
DBCC TRACEON (3604);
GO
DBCC PAGE ('RowStructure', 1, 89, 3);
GO
Trong đầu ra từ TRANG DBCC, chúng ta thấy c1 được nhồi với ký tự 'A' trước c2 'B':
Memory Dump @0x000000000D25A060
0000000000000000: 10001c00 01000000 41414141 41414141 †........AAAAAAAA
0000000000000010: 41414242 42424242 42424242 030000††††AABBBBBBBBBB...
Và chỉ vì, cho phép mở RowStructure.mdfbằng trình chỉnh sửa hex và xác nhận chuỗi 'A' trước chuỗi 'B':
Bây giờ lặp lại thử nghiệm nhưng đảo ngược thứ tự của các chuỗi, đặt các ký tự 'B' vào c1 và các ký tự 'A' trong 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
Lần này, đầu ra TRANG DBCC của chúng tôi khác và chuỗi 'B' xuất hiện đầu tiên:
Memory Dump @0x000000000FC2A060
0000000000000000: 10001c00 01000000 42424242 42424242 †........BBBBBBBB
0000000000000010: 42424141 41414141 41414141 030000††††BBAAAAAAAAAA...
Một lần nữa, chỉ để cười khúc khích, hãy kiểm tra kết xuất hex của tệp dữ liệu:
Như Anatomy of a Record giải thích, các cột có chiều dài cố định và thay đổi của bản ghi được lưu trữ trong các khối riêng biệt. Hợp lý xen kẽ các loại cột cố định và biến đổi không có ảnh hưởng đến hồ sơ vật lý. Tuy nhiên, trong mỗi khối, thứ tự các cột của bạn sẽ ánh xạ tới thứ tự byte trong tệp dữ liệu.
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
Xem thêm:
Thứ tự cột không quan trọng nói chung, nhưng - TIỀN GỬI CNTT!
CREATE TABLEcâu lệnh (ngoại trừ các cột khóa CI xuất hiện đầu tiên trong phần). Mặc dù thứ tự của các cột có thể thay đổi nếuALTER COLUMNthay đổi kiểu dữ liệu / độ dài cột. Trường hợp nhỏ duy nhất mà tôi có thể nghĩ đến là các cột ở cuối phần có độ dài thay đổi với chuỗi rỗng hoặc NULL không có khoảng trống nào trong mảng bù cột (được Kalen Delaney trình bày trong sách nội bộ 2008)