GUID vs INT 主鍵效能實測：插入、查詢、聯結、儲存空間四維對比

實測環境：Pentium 4 3.06GHz、1.5GB RAM、SQL Server 2005 Personal

建立兩表：`Test_Guid` (PK `UNIQUEIDENTIFIER`/`VARCHAR(50)`) vs `Test_Int` (PK `IDENTITY INT`)，欄位相同 (`TestId INT`, `TestText NTEXT`, `TestDateTime DATETIME`)。

測試腳本框架

-- Test_Guid
CREATE TABLE Test_Guid (
    Guid VARCHAR(50) NOT NULL,
    TestId INT NOT NULL,
    TestText NTEXT NOT NULL,
    TestDateTime DATETIME DEFAULT GETDATE(),
    CONSTRAINT PK_Guid PRIMARY KEY (Guid)
);

-- Test_Int
CREATE TABLE Test_Int (
    Id INT NOT NULL IDENTITY(1,1),
    TestId INT NOT NULL,
    TestText NTEXT NOT NULL,
    TestDateTime DATETIME DEFAULT GETDATE(),
    CONSTRAINT PK_Id PRIMARY KEY (Id)
);

預期差異 (理論 + 經驗)

實測建議指標

1. **插入 10 萬筆耗時** (單筆 `INSERT` vs 批次 `TVP`/`BULK`)。
2. **索引碎片率** (`sys.dm_db_index_physical_stats`)。
3. **PK 聯結查詢** (10 萬筆關聯 100 萬筆) 邏輯讀/CPU/耗時。
4. **資料表大小** (`sp_spaceused`)。

決策指南

• **單機/叢集、高寫入、聯結頻繁、無異地合併需求** → **`BIGINT IDENTITY`** (或 `INT` 足夠大)。
• **多機寫入、離線同步、合併複寫、微服務分散式 ID** → **`UNIQUEIDENTIFIER` + `NEWSEQUENTIALID()`** (或應用層生成有序 UUID v7/ULID)。
• **絕對避免 `VARCHAR(36)` 存 GUID** → 浪費空間、排序錯誤 (字典序 vs 位元序)、索引效能最差。

現代補充：SQL Server 2017+ `NEWSEQUENTIALID()` 限制

僅能作 `DEFAULT` 約束，不可在 `SELECT`/`SET` 中直接呼叫。應用層生成有序 UUID (RFC 9562 UUID v7、ULID、TSID) 後傳入，**兼具全域唯一與插入順序**，為最佳實務。