N 72最好下载怎么uc版本大全的UC

来源：蜘蛛抓取(WebSpider) 时间：2012-04-26 02:35 标签： uc版本大全

题记：整改公司以前的商城数据打开数据库，看到原项目中所有的表主键都是uuid并且所有表都没有注释，我表示一脸懵逼由于该表是领导以前找的一个人做的，好吧联系人去。

由主键引发的“血案”就这么开始了这个框架是之前的人自己写的，里面主键全是uuid我跟他建议说MySQL最好使用自增主键，效率更高innoDB的索引特性导致了自增id做主键是效率最好的，为了拿实际的案例来说服他所以准备做个详细的测试 

USER，自增ID为主键表结构类似洳下：
 
二：1000万数据开始测试
  
 
 

 
 

 
 

 假如规划48个节点组，N为48现在配置第8个节点组，这个i为8第8个节点组的my.cnf里面的配置为：
 
 

 
 

 
 
  
3.2）UUID，适合小规模的分布式环境
  
 

 对于InnoDB这种聚集主键类型的引擎来说数据会按照主键进行排序，由于UUID的无序性InnoDB会产生巨大的IO压力，而且由于索引和数据存储在一起字符串做主键会造成存储空间增大一倍。

 

 在存储和检索的时候innodb会对主键进行物理排序，这对auto_increment_int是个好消息因为后一次插入的主键位置总是在最后。但是对uuid来说这却是个坏消息，因为uuid是杂乱无章的每次插入的主键位置是不确定的，可能在开头也可能在中间，在进荇主键物理排序的时候势必会造成大量的
 IO操作影响效率，在数据量不停增长的时候特别是数据量上了千万记录的时候，读写性能下降嘚非常厉害
 
 

 优点：搭建比较简单，不需要为主键唯一性的处理
 
 

 缺点：占用两倍的存储空间（在云上光存储一块就要多花2倍的钱），后期读写性能下降厉害
 
 

 
 
  
（1）：单实例或者单节点组3.2
  
 

 经过500W、1000W的单机表测试，自增ID相对UUID来说自增ID主键性能高于UUID，磁盘存储费用比UUID节省一半的錢所以在单实例上或者单节点组上，使用自增ID作为首选主键
 
 

 20个节点组下的小型规模的分布式场景，为了快速实现部署可以采用多花存储费用、牺牲部分性能而使用UUID主键快速部署；

 

 20到200个节点组的中等规模的分布式场景，可以采用自增ID+步长的较快速方案
 
 

 200以上节点组的大數据下的分布式场景，可以借鉴类似twitter雪花算法构造的全局自增ID作为主键
 
 

 客官，点击下方打赏一个呗~
 




                            

                                                

                    

                

            

            


            

                
我要回帖

                

                    

                        
                        
                    

                

            

            

                        

                
更多关于 uc版本大全 的文章

                

                    
                

            

                    

        

            

                
 

                


                

            

            

            

                
随机推荐