今天上班，發(fā)現(xiàn)一個(gè)同事用oracle的sys_guid()來做從一個(gè)表中隨機(jī)獲取6條記錄：
select * from (select * from tablename order by sys_guid()) where rownum < 7;
看得出來是先創(chuàng)建guid，然后將表記錄按照這個(gè)guid排序，再從中取頭6條。
數(shù)據(jù)庫主鍵用guid我倒是見過，這樣用作取隨機(jī)數(shù)倒是頭一次碰上。

立刻又想到oracle用guid作主鍵，跟sequnce比較哪個(gè)更好。google中還是找到了一篇文章說的比較好：

http://sgsoft.itpub.net/post/28147/270097

?

最近又有朋友爭論起 SYS_GUID 與 sequence 誰做主鍵更合適的問題。下面我以一個(gè)案例說明一下，兩者在實(shí)際應(yīng)用中的情況。以下內(nèi)容純屬個(gè)人研究，觀點(diǎn)亦僅限于本案例

記得A項(xiàng)目組是一個(gè)物流管理系統(tǒng)，后臺采用了Oracle數(shù)據(jù)庫。在系統(tǒng)中的核心表托運(yùn)單表中，關(guān)于主鍵采用何種數(shù)據(jù)類型，是 sequence 還是用 GUID ， 大家起了爭論。

從網(wǎng)絡(luò)搜索得到的結(jié)論看，一般的意見總結(jié)為：
1. SYS_GUID()比sequence復(fù)雜；
2.SYS_GUID做主鍵，則表、索引存儲(chǔ)開銷多；
3.SYS_GUID索引查詢比sequence慢； 下面對SYS_GUID和Sequence做主鍵的情況進(jìn)行以下對比.
edl@PISC> select count(*) from all_objects;

COUNT(*)

----------

50231

已用時(shí)間 : 00: 00: 02.52

創(chuàng)建下列對象：

create table tsg as select RAWTOHEX(sys_guid()) sgid,a.* from all_objects a;

create SEQUENCE seq_tsg;

create table tsg2 as select seq_tsg.nextval,a.* from all_objects a;

空間比較

現(xiàn)在這兩個(gè)表：tsg和tsg2擁有的行數(shù)相同，但大小不同：

表	行數(shù)	Number Extents	Size in bytes	索引大小
TSG（SYS_GUID主鍵）	50231	23	8388608	3145728
TSG2（Sequence主鍵）	50231	21	6291456	917504

換言之 ， 相同條件下 ， 使用 SYS_GUID 做主鍵比用 Sequence 做主鍵 ，表 多消耗了空間 2097152 byte, 索引多消耗 2228224 byte, 平均每行多消耗 86.1 byte.

考慮到生產(chǎn)環(huán)境下 , 每天 5 萬條記錄 , 則一年 365*50000=18250000 條記錄 , 則理論上需要多耗費(fèi)空間約合 1.43GB 存儲(chǔ)空間 . 這些空間對磁盤消耗而言可以忽略不計(jì)，對內(nèi)存仍然是有一定影響的，但就當(dāng)前的服務(wù)器能力而言，影響有限，如果對表進(jìn)行合理分區(qū)后，這種影響可以降低至極低。

執(zhí)行計(jì)劃比較

比較唯一查詢時(shí)的執(zhí)行計(jì)劃 :

對 TSG 執(zhí)行 :

select owner

from tsg

where sgid = 'F36C09B7A7A84297995352D2409EB40E'

對 TSG2 執(zhí)行 :

select owner

from tsg2

where sgid = 99

執(zhí)行計(jì)劃比較如下 :

統(tǒng)計(jì)信息對比 :

從以上統(tǒng)計(jì)信息看 , 執(zhí)行計(jì)劃相同。
可以預(yù)料到的是 , 由于使用 SYS_GUID 做主鍵 , 比較的是字符串 , 故耗費(fèi) CPU 要高些 , 因此 ,logical reads 要高些 , 至于 Physical Readers 居然低一些 , 就不知道原因了（實(shí)際上二者基本都沒有產(chǎn)生大量的物理讀） , 估計(jì)是我的測試環(huán)境 Db Cache 太小的緣故 .

對于響應(yīng)時(shí)間 , 這應(yīng)該是計(jì)算機(jī)環(huán)境產(chǎn)生的影響 , 不能說明問題，這兩條語句響應(yīng)都很快 , 小于 0.02 秒 .

小結(jié)

從實(shí)踐來看 , 使用 SYS_GUID() 做主鍵的優(yōu)點(diǎn)多于負(fù)面影響。特別是在多個(gè)數(shù)據(jù)庫數(shù)據(jù)集成時(shí) ,GUID 的優(yōu)點(diǎn)顯而易見 . A項(xiàng)目最終沒有采用客戶定義的“貨單唯一序號”作為主鍵，也是出于關(guān)系數(shù)據(jù)庫設(shè)計(jì)的法則約定：“主鍵不要代表任何意義”。

綜上所述， SYS_GUID 做主鍵：

SYS_GUID 比 sequence 復(fù)雜 === è 有限范圍的正確 ：由于 SYS_GUID 是 RAW 類型的，做主鍵是，需要使用 RAWTOHEX 或者 HEXTORAW 類的函數(shù)轉(zhuǎn)換，若直接使用，則需要建立函數(shù)索引等。但這種復(fù)雜性往往在前端業(yè)務(wù)系統(tǒng)中體現(xiàn)不出，主鍵常常作為隱含的唯一 ID 去標(biāo)識對象，而不顯示出來（或者不手工操作它，因?yàn)樗鼰o意義）。

SYS_GUID 做主鍵存儲(chǔ)開銷大 = è 不需要評估系統(tǒng)規(guī)模：如今存儲(chǔ)非常便宜，內(nèi)存也足夠大，如果 2 千萬條記錄增加不到1.5G內(nèi)存的話，當(dāng)前普通的服務(wù)器已經(jīng)可以承受，如果進(jìn)行合理分區(qū)，則影響可以降低到極低。當(dāng)然，如果您的服務(wù)器資源很緊張，那恐怕得放棄使用SYS_GUID

SYS_GUID 做主鍵查詢比 sequence 慢 è 不正確：實(shí)踐證明，二者是一樣的。

?

guid跟sequence做主鍵的比較