数据库主键策略的一些感想

目前在做一个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以内．

大家有什么好的建义，参考参考。

一般情况下同一系统中32位（8个字符的16进制表示）的主键就很难有重复，更保守一点的就是128位（32个字符的16进制表示）的主键了。
你要使用日期+随机数的表示，yyMMddHHmmss就已经12位了，后面精确到毫秒在加至少3位随机数就18位长了，其实也不短，呵呵。

20位是太长了。所要压缩到10位。压缩方式就是把10进制改成正64进制，也就是说每一个位上可以有６４种状态。日期表示也不定要yyMMddHHmmss的形式，可以用从2008-08-23 24:00:00:000开始到现在毫秒数。故计这么做可以压缩在10位以内，具体还没有编程。

索引用整形比用字符串性能好吧。

自制sequence做好是不应该有效率问题的，而且有高度数据库平台无关性的优点，不过要确保任何情况的ID的唯一性，如系统崩溃时怎么保证ID的唯一性，这需要一些技巧。

字符串可能效率会不够。
可以考虑这样的策略：
类似用户id分配，每个数据库给个编号，每个自增长初始值错开，步长设置超过数据库数量，例如：
1, 11, 21, 31, ...
2, 12, 22, 32, ...

自己写一个序列生成器，利用数据库提供的机制会让你的系统绑定在特定数据库平台之下。建立一个数据库表，一个列存储序列号名，一个列存储序列号的当前值，然后，提供一个开发接口，每次调用都把这个值增大。至于实现方式你可以提供缓冲方式来生成可以提高并发访问性能。
我们已经采用这种方案N年了，实践证明很好用。

据我的经验，数据库的主键用整数最好，可以考虑长整型的。
一个表一般只需要一个字段作为主键。表示关系的表一般用两个字段联合作为主键。如果出现三个字段作为联合主键，那么就应当考虑设计是否合理了。