mysql 生成唯一全局主键ID

mysql生成全局唯一ID

全局唯一ID生成策略多种多样,这里列举几例以供参考。

1 使用auto_increment_increment和auto_increment_offset
  这两个服务器变量可以让mysql以期望的值和偏移量来增加auto_increment列的值。
  举个例子,两台服务器,可以配置这两台服务器自增步长都是2，其中一台的偏移量设置为1，另一台设置为2，
  这样每台服务器生成的ID就是唯一不重复的。同理,配置3台服务器,初始值为 1、2、3 统一步长为3,则每台服务器生成的
  ID就是唯一不重复的。这种方法相对简单,并且不依赖于某个节点,因此是生成唯一ID的比较普遍的做法。但是其缺点也是名叫明显,
  需要非常仔细的配置服务器,很容易因为配置错误生成重复数字,特别是当增加服务器需要改变其角色或进行灾难恢复时。
  
  缺陷：
1) 在大表做水平分表时，就不能使用自增Id，因为Insert的记录插入到哪个分表依分表规则判定决定，若是自增Id，各个分表中Id就会重复，在做查询、删除时就会有异常。
2) 在对表进行高并发单记录插入时需要加入事物机制，否则会出现Id重复的问题。
3) 在业务上操作父、子表（即关联表）插入时，需要在插入数据库之前获取max(id)用于标识父表和子表关系，若存在并发获取max(id)的情况，max(id)会同时被别的线程获取到。

  此种方式适合小应用,无需分表,没有高并发性能要求。	
2 在全局节点中创建表
  在一个全局数据库节点中创建一个包含auto_increment列的表,应用可以通过这个表来生成唯一数字。
  1)使用MaxId表存储各表的MaxId值
    专门一个数据库，记录各个表的MaxId值，建一个存储过程来取Id，逻辑大致为：开启事物，对于在表中不存在记录，直接返回一个默认值为1的键值，同时插入该条记录到table_key表中。而对于已存在的记录，key值直接在原来的key基础上加1更新到MaxId表中并返回key。
    使用此方案的问题是：每次的查询MaxId是一个性能损耗；不过不会像自增序列表那么容易列暴掉，因为是摆表进行划分的。
  
3 使用memcached
  在memcached的API中有一个incr函数，可以自动增长一个数字并返回。

4 批量分配数字
  应用可以从一个全局节点中请求一批数字，用完后再申请。
  
5 使用多台ID生成器 
 建立两台以上的数据库ID生成服务器，每个服务器都有一张记录各表当前ID的MaxId表，但是MaxId表中Id的增长步长是服务器的数量，起始值依次错开，
 这样相当于把ID的生成散列到每个服务器节点上。例如：如果我们设置两台数据库ID生成服务器，那么就让一台的MaxId表的Id起始值为1（或当前最大Id+1），
 每次增长步长为2，另一台的MaxId表的ID起始值为2（或当前最大Id+2），每次步长也为2。这样就将产生ID的压力均匀分散到两台服务器上，同时配合应用程序控制，当一个服务器失效后，
 系统能自动切换到另一个服务器上获取ID，从而解决的单点问题保证了系统的容错。（Flickr思想）
 但是要注意：1、多服务器就必须面临负载均衡的问题；2、倘若添加新节点，需要对原有数据重新根据步长计算迁移数据。
 结论：适合大型应用，生成Id较短，友好性比较好。（强烈推荐）
 
 6 “COMB”（combined guid/timestamp，意思是：组合GUID/时间截）
   COMB数据类型的基本设计思路是这样的：既然GUID数据因毫无规律可言造成索引效率低下，影响了系统的性能，那么能不能通过组合的方式，保留GUID的10个字节，
   用另6个字节表示GUID生成的时间（DateTime），这样我们将时间信息与GUID组合起来，在保留GUID的唯一性的同时增加了有序性，以此来提高索引效率。
   /// <summary> /// Generate a new <see cref="Guid"/> using the comb algorithm.
/// </summary> 
private Guid GenerateComb()
{
    byte[] guidArray = Guid.NewGuid().ToByteArray();
 
    DateTime baseDate = new DateTime(1900, 1, 1);
    DateTime now = DateTime.Now;
 
    // Get the days and milliseconds which will be used to build   
    //the byte string    
    TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks);
    TimeSpan msecs = now.TimeOfDay;
 
    // Convert to a byte array        
    // Note that SQL Server is accurate to 1/300th of a   
    // millisecond so we divide by 3.333333    
    byte[] daysArray = BitConverter.GetBytes(days.Days);
    byte[] msecsArray = BitConverter.GetBytes((long)
      (msecs.TotalMilliseconds / 3.333333));
 
    // Reverse the bytes to match SQL Servers ordering   
    Array.Reverse(daysArray);
    Array.Reverse(msecsArray);
 
    // Copy the bytes into the guid    
    Array.Copy(daysArray, daysArray.Length - 2, guidArray,
      guidArray.Length - 6, 2);
    Array.Copy(msecsArray, msecsArray.Length - 4, guidArray,
      guidArray.Length - 4, 4);
 
    return new Guid(guidArray);
}
结论：适合大型应用。即保留GUID的唯一性的同时增加了GUID有序性，提高了索引效率；解决了关联表业务问题；生成的Id不够友好；占据了32位。（强烈推荐）

7 另外互联网上有比较流行的借鉴flicker 和twitter 的做法，可以借鉴。
  
参考   http://blog.csdn.net/houkai6/article/details/17713845
http://my.oschina.net/u/142836/blog/174465
  
  

   请尊重知识，请尊重原创 更多资料参考请见  http://www.cezuwang.com/listFilm?page=1&areaId=906&filmTypeId=1