13518219792
Mysql中主键UUID和自增主键有什么区别？针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
创新互联公司是一家集网站建设,盐城企业网站建设,盐城品牌网站建设,网站定制,盐城网站建设报价,网络营销,网络优化,盐城网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。1. 避免重复，便于scale，这就是我们做cloud service的时候选择uuid的主要原因
2. 入库之前可以知道id
3.相对安全，不能简单的从uuid获取信息，但是如果自增，则容易暴露信息，如果一个客户id是123456，很容易猜到有客户id是123456.
1.uuid有16个字节，比int（4 byte）和bigint（8 byte）占用更多存储空间
2.由于size和无序性，可能引起性能问题
mysql的innodb存储引擎处理storage的方式是靠聚集索引。
聚集索引是指数据库表行中数据的物理顺序与键值的逻辑（索引）顺序相同。一个表只能有一个聚集索引，因为一个表的物理顺序只有一种情况
(1).其实在innodb存储引擎下，自增长的id做主键性能已经达到了很好。不论是存储和读取速度都是最快的，而且占的存储空间也是最小。
(2).但是在我们实际到项目中会碰到问题，历史数据表的主键id会与数据表的id重复，两张自增id做主键的表合并时，id一定会有冲突，但如果各自的id还关联了其他表，这就很不好操作。
(3).如果使用UUID，生成的ID不仅是表独立的，而且是库独立的。对以后的数据操作很有好处，可以说一劳永逸。
缺点： 1. 影响插入速度， 并且造成硬盘使用率低
2. uuid之间比较大小相对数字慢不少， 影响查询速度。
3. uuid占空间大， 如果你建的索引越多， 影响越严重
优点：出现数据拆分、合并存储的时候，能达到全局的性
(1).InnoDB引擎表是基于B+树的索引组织表。
(2).B+树：B+树是为磁盘或其他直接存取辅助设备而设计的一种平衡查找树，在B+树中，所有记录节点都是按键值的大小顺序存放在同一层的叶节点中，各叶节点指针进行连接。
(3).InnoDB主索引：叶节点包含了完整的数据记录。这种索引叫做聚集索引。InnoDB 的索引能提供一种非常快速的主键查找性能。不过，它的辅助索引也会包含主键列，所以，如果主键定义的比较大，其他索引也将很大。如果想在表上定义 、很多索引，则争取尽量把主键定义得小一些。InnoDB 不会压缩索引
(4).聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引：首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。
综合上述可得：
(1).如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是高的。为了存储和查询性能应该使用自增长id做主键。
(2).对于InnoDB的主索引，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，此时不适合使用UUID做物理主键，可以把它作为逻辑主键，物理主键依然使用自增ID。为了全局的性，应该用uuid做索引关联其他表或做外键。
如果是主从即M-S模式，好是不使用mysql自带函数uuid来生成主键，因为主表生成的uuid要再关联从表时，需要再去数据库查出这个uuid，需要多进行一次数据库交互，而且在这个时间差里面主表很有可能还有数据生成，这样就很容易导致关联的uuid出错。如果真要使用uuid，可以在Java中生成后，直接存储到DB里，这时主从的uuid就是一样的了！
补充：mysql的uuid()主键重复
mysql使用了navicat客户端，某次执行了如下sql
select replace(uuid(), '-', '') as id, u.user_id from t_user u;
结果发现，生成的uuid重复了，
经过排查，发现是navicat的问题，需要将该sql语句做如下调整:
select replace(convert(uuid() using utf8mb4), '-', ''), u.user_id from t_user u;
结果如下：
将uuid再进行一次md5：
select md5(uuid()) as id, u.user_id from t_user u;
关于Mysql中主键UUID和自增主键有什么区别问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注创新互联行业资讯频道了解更多相关知识。
