guid跟sequence做主键的比较

今天上班，发现一个同事用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拥有的行数相同，但大小不同：

换言之 ， 相同条件下 ， 使用 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 做主键存储开销大= è

SYS_GUID 做主键查询比 sequence 慢 è