我可能在這里遺漏了一些東西（如果我愿意，可以隨意糾正我），但我可以看到使用順序GUID / UUID作為主鍵的好處很少。

該點使用的GUID或UUID的在自動遞增的整數是：

• 它們可以在任何地方創建而無需聯系數據庫

• 它們是在您的應用程序中完全唯一的標識符（在UUID的情況下，通用唯一）

• 給定一個標識符，沒有辦法猜測在暴力之外的下一個或前一個（甚至任何其他有效標識符） - 強制一個巨大的密鑰空間。

不幸的是，使用你的建議，你會失去所有這些東西。

所以，是的。你已經使GUID變得更好了。但是在這個過程中，你幾乎拋棄了幾乎所有使用它們的理由。

如果您真的想提高性能，請使用標準的自動增量整數主鍵。這提供了您所描述的所有好處（以及更多），而幾乎在所有方面都優于“順序指導”。

這很可能會被遺忘，因為它沒有專門回答你的問題（這顯然是精心制作的，所以你可以立即自己回答），但我覺得這是一個更重要的一點。

正如massimogentilini已經說過的，使用UuidCreateSequential時可以提高性能（在代碼中生成guid時）。但似乎缺少一個事實：SQL Server（至少Microsoft SQL 2005/2008）使用相同的功能，但是：Guids的比較/排序在.NET和SQL Server上有所不同，這仍然會導致更多的IO，因為guid不會被正確訂購。為了生成為sql server（訂購）正確訂購的guid，您必須執行以下操作（請參閱比較詳細信息）：

[System.Runtime.InteropServices.DllImport("rpcrt4.dll", SetLastError = true)]static extern int UuidCreateSequential(byte[] buffer);static Guid NewSequentialGuid() {
    byte[] raw = new byte[16];
    if (UuidCreateSequential(raw) != 0)
        throw new System.ComponentModel.Win32Exception(System.Runtime.InteropServices.Marshal.GetLastWin32Error());
    byte[] fix = new byte[16];
    // reverse 0..3
    fix[0x0] = raw[0x3];
    fix[0x1] = raw[0x2];
    fix[0x2] = raw[0x1];
    fix[0x3] = raw[0x0];
    // reverse 4 & 5
    fix[0x4] = raw[0x5];
    fix[0x5] = raw[0x4];
    // reverse 6 & 7
    fix[0x6] = raw[0x7];
    fix[0x7] = raw[0x6];
    // all other are unchanged
    fix[0x8] = raw[0x8];
    fix[0x9] = raw[0x9];
    fix[0xA] = raw[0xA];
    fix[0xB] = raw[0xB];
    fix[0xC] = raw[0xC];
    fix[0xD] = raw[0xD];
    fix[0xE] = raw[0xE];
    fix[0xF] = raw[0xF];
    return new Guid(fix);}

或此鏈接或此鏈接。