TA貢獻(xiàn)1900條經(jīng)驗(yàn) 獲得超5個(gè)贊
我可能在這里遺漏了一些東西（如果我愿意，可以隨意糾正我），但我可以看到使用順序GUID / UUID作為主鍵的好處很少。
該點(diǎn)使用的GUID或UUID的在自動(dòng)遞增的整數(shù)是：
它們可以在任何地方創(chuàng)建而無(wú)需聯(lián)系數(shù)據(jù)庫(kù)
它們是在您的應(yīng)用程序中完全唯一的標(biāo)識(shí)符（在UUID的情況下，通用唯一）
給定一個(gè)標(biāo)識(shí)符，沒有辦法猜測(cè)在暴力之外的下一個(gè)或前一個(gè)（甚至任何其他有效標(biāo)識(shí)符） - 強(qiáng)制一個(gè)巨大的密鑰空間。
不幸的是，使用你的建議，你會(huì)失去所有這些東西。
所以，是的。你已經(jīng)使GUID變得更好了。但是在這個(gè)過程中，你幾乎拋棄了幾乎所有使用它們的理由。
如果您真的想提高性能，請(qǐng)使用標(biāo)準(zhǔn)的自動(dòng)增量整數(shù)主鍵。這提供了您所描述的所有好處（以及更多），而幾乎在所有方面都優(yōu)于“順序指導(dǎo)”。
這很可能會(huì)被遺忘，因?yàn)樗鼪]有專門回答你的問題（這顯然是精心制作的，所以你可以立即自己回答），但我覺得這是一個(gè)更重要的一點(diǎn)。
TA貢獻(xiàn)1806條經(jīng)驗(yàn) 獲得超8個(gè)贊
正如massimogentilini已經(jīng)說過的，使用UuidCreateSequential時(shí)可以提高性能（在代碼中生成guid時(shí)）。但似乎缺少一個(gè)事實(shí)：SQL Server（至少M(fèi)icrosoft SQL 2005/2008）使用相同的功能，但是：Guids的比較/排序在.NET和SQL Server上有所不同，這仍然會(huì)導(dǎo)致更多的IO，因?yàn)間uid不會(huì)被正確訂購(gòu)。為了生成為sql server（訂購(gòu)）正確訂購(gòu)的guid，您必須執(zhí)行以下操作（請(qǐng)參閱比較詳細(xì)信息）：
[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);}舉報(bào)