请问对于数据库的主键究竟要不要用自增id呢?
谢谢邀请!这个问题跟具体业务场景和技术实现有关:
1、业务场景:例如订单、支付单号等比较敏感的肯定不能自增了,都是安全级别很高的字段,需要唯一id作为主键。
2、技术实现:在实际开发过程中批量导入或处理数据的时候要考虑到技术实现的性能那么要多方面验证用自增主键还是非自增主键了。
mysql分库分表之后,id主键如何处理?
我从分库分表存在的问题和怎么做来回答一下这个问题。。
一,
通常使用外接的数据组件获取全局唯一的id:比如加强型uuid(根据ip,时间戳等得到)和使用redis(redisatomiclong)和zookeeper的api获取,twitter的雪花算法等等!
二,
问题没法避免,通常拆分sql,使用多次查询,用查到的结果再分别查别的结果!
三,
可以使用tcc编程模型保证两处的事务都能正确提交,但是这种方式对代码的侵入比较重!也可以使用基于消息的数据一致性保证!
四,
1,用多线程,对多个节点分别查询,然后汇总!
2,也可以提前冗余查询表,将所有的经常查询的重点数据提前统一到个库表里!
原文标题:uuid和自增id优缺点 请问对于数据库的主键究竟要不要用自增id呢?,如若转载,请注明出处:https://www.saibowen.com/wenda/23178.html
免责声明:此资讯系转载自合作媒体或互联网其它网站,「赛伯温」登载此文出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,文章内容仅供参考。