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

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

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

?

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

記得A項目組是一個物流管理系統，后臺采用了Oracle數據庫。在系統中的核心表托運單表中，關于主鍵采用何種數據類型，是 sequence 還是用 GUID ， 大家起了爭論。

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

COUNT(*)

----------

50231

已用時間 : 00: 00: 02.52

創建下列對象：

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;

空間比較

現在這兩個表：tsg和tsg2擁有的行數相同，但大小不同：

表	行數	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.

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

執行計劃比較

比較唯一查詢時的執行計劃 :

對 TSG 執行 :

select owner

from tsg

where sgid = 'F36C09B7A7A84297995352D2409EB40E'

對 TSG2 執行 :

select owner

from tsg2

where sgid = 99

執行計劃比較如下 :

統計信息對比 :

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

對于響應時間 , 這應該是計算機環境產生的影響 , 不能說明問題，這兩條語句響應都很快 , 小于 0.02 秒 .

小結

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

綜上所述， SYS_GUID 做主鍵：

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

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

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

?

guid跟sequence做主鍵的比較