Oracle中的:sys_guid唯一標識和傳統的序列sequence的區別

Oracle中的:sys_guid唯一標識和傳統的序列sequence的區別

SYS_GUID (),是Oracle 8i 後提供的函數。SYS_GUID產生並返回一個全球唯一的標識符(原始值)由16個字節組成。例如:SELECT sys_guid() from dual
Oracle8i引入了SYS_GUID這個概念,它同Oracle管理員所使用的傳統的序列(sequence)相比具有諸多優勢。一個序列生成器只是簡單地創建從給定的起點開始的一系列整數值,而且它被用在選擇陳述式的時候自動地遞增該系列。
序列生成器所生成的數字只能保證在單個實例裏是唯一的,這就不適合將它用作並行或者遠程環境裏的主關鍵字,因爲各自環境裏的序列可能會生成相同的數字,從而導致衝突的發生。SYS_GUID會保證它創建的標識符在每個數據庫裏都是唯一的。
序列必須是DML陳述式的一部分,因此它需要一個到數據庫的往返過程(否則它就不能保證其值是唯一的)。SYS_GUID源自不需要對數據庫進行訪問的時間戳和機器標識符,這就節省了查詢的消耗。
很多應用程序都依靠序列生成器來創建數據行的主關鍵字,這些數據行沒有一個明顯的主值,這也就是說,在這樣的數據集裏一條記錄的創建就會讓數據列發生改變。因此,管理員可能會對在表格中將SYS_GUID用作主關鍵字而不使用序列數感興趣。這在對象在不同機器的不同數據庫裏生成以及需要在後來合併到一起的情況下很有用。
但是,SYS_GUID所生成的值是一個16個字節的原始值。序列所生成的整數不會使用16字節(的值),除非它達到了10的30次方(每個字節兩個16進制顯示位),而且數字是相當獨特的:
SQL> select dump(123456789012345678901234567890) from dual;
DUMP(123456789012345678901234567890)
--------------------------------------------------------------
Typ=2 Len=16: 207,13,35,57,79,91,13,35,57,79,91,13,35,57,79,91
使用SYS_GUID或者序列會在數據庫使用週期裏的某些地方造成性能上的消耗;問題就是在那裏。對於SYS_GUID而言,性能上的影響在查詢時間和創建時間上(在表格裏要創建更多的塊和索引以容納數據)。對序列而言,性能上的影響在查詢期間,在這個時候,SGA序列的緩衝區被用光。在缺省情況下,一個序列一次會緩衝20個值。如果數據庫沒有使用這些值就關閉了,它們就會被丟失。
SYS_GUID生成的值的另一個顯著的不足之處是,管理這些值會變得困難得多。你必須(手動)輸入它們或者通過腳本來填充它們,或者將它們作爲Web參數來傳遞。

性能比較:

創建下列對象:
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項目最終沒有采用客戶定義的“貨單唯一序號”作爲主鍵,也是出於關係數據庫設計的法則約定:“主鍵不要代表任何意義”。
 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章