日期:2014-05-16  浏览次数:20458 次

数据库主键策略的一些感想
目前在做一个Rss收集相关的web系统。

1.数据库是使用多台mysql。
2.用mysql 的 replication来分离读写。
3.根据用户ID来分布数据库中的数据。

问题:
1.mysql没有像oracle中的sequence。自制sequence的话怕影响效率。
2.采用mysql中的自增长主键,在分布数据库中会有重复主键问题。键值必须在多个数据库中惟一。
3.在网上查了几个程序生成的主键的方式,似乎都很长最长的要128位,这对与键索引来说会太大。
4.用时间到毫秒在加5位随机数来生成主键,但这也要20位,还是不理想。

查询了公司之前项目的主键生成机制。
发现了原项目中用了Oracle的sequence,并用一procedure把数字sequence压缩成字母大小写在加数字的形式。就是把原来的10进变成64进制,相应的位数就减少了很多。

最后决定用php来写一个压缩数字日期加随机数的程序来做,把主键限定在10以内.

大家有什么好的建义,参考参考。
1 楼 Zmud 2007-08-23  
一般情况下同一系统中32位(8个字符的16进制表示)的主键就很难有重复,更保守一点的就是128位(32个字符的16进制表示)的主键了。
你要使用日期+随机数的表示,yyMMddHHmmss就已经12位了,后面精确到毫秒在加至少3位随机数就18位长了,其实也不短,呵呵。
2 楼 graymood 2007-08-23  
Zmud 写道
一般情况下同一系统中32位(8个字符的16进制表示)的主键就很难有重复,更保守一点的就是128位(32个字符的16进制表示)的主键了。
你要使用日期+随机数的表示,yyMMddHHmmss就已经12位了,后面精确到毫秒在加至少3位随机数就18位长了,其实也不短,呵呵。


20位是太长了。所要压缩到10位。压缩方式就是把10进制改成正64进制,也就是说每一个位上可以有64种状态。日期表示也不定要yyMMddHHmmss的形式,可以用从2008-08-23 24:00:00:000开始到现在毫秒数。故计这么做可以压缩在10位以内,具体还没有编程。
3 楼 onlytiancai 2007-08-31  
索引用整形比用字符串性能好吧。
4 楼 fight_bird 2007-10-01  
自制sequence做好是不应该有效率问题的,而且有高度数据库平台无关性的优点,不过要确保任何情况的ID的唯一性,如系统崩溃时怎么保证ID的唯一性,这需要一些技巧。
5 楼 birdjavaeye 2007-10-02  
字符串可能效率会不够。
可以考虑这样的策略:
类似用户id分配,每个数据库给个编号,每个自增长初始值错开,步长设置超过数据库数量,例如:
1, 11, 21, 31, ...
2, 12, 22, 32, ...