最近在做数据库设计的时候(以MySQL为主),遇到不少困惑,因为之前做数据库表设计,基本上主键都是使用自增的形式,最近因为这种做法,被领导指出存在一些不足,于是我想搞明白哪里不足。
通过网上查阅资料,得出一个这样的结论:
表的主键一般都要使用自增 id,不建议使用业务id ,是因为使用自增id可以避免页分裂。
按照我过去的实践:
选择使用自增可以避免很多麻烦,主要体现是数据的唯一性(从1到xxx,肯定不会重复的)。
这块我没看太明白,我主要参考如下链接:
一看就懂的:MySQL数据页以及页分裂机制
为什么?mysql不推荐使用uuid或者雪花id作为主键?
拖库:指黑客通过各种社工手段、技术手段将数据库中敏感信息非法获取,一般这些敏感信息包括用户的账号信息如用户名、密码;身份信息如真实姓名、证件号码;通讯信息如电子邮箱、电话、住址等。
参考链接:
MySQL主键应该用UUID还是INT类型
一分钟让你了解拖库、洗库和撞库
简要概括UUID的适用场景:主要适合用在大型项目微服务架构中,保证全局ID唯一性(大型项目微服务架构集成各式各样的子系统,避免ID冲突)。
起初我在数据表设计的时候就与项目经理争论过,挺类似这个链接的对话:UUID与数字ID的区别与适用场景
指用2个或者是2个以上的字段组成的主键,用这个主键包含的字段作为主键,这个组合在数据表中是唯一,且附加上了主键索引。
我能想到一个用户信息,针对某个一个区域如果用用户ID或用户ID+用户姓名作为主键,难以保持数据的唯一性,因为这一个地区不仅仅是有一个小马哥,可能有七八个人,如此,前面提到的用户ID或用户ID+用户姓名显然是行不通的,这时可以把SFZ加入主键,变成了用户ID+用户姓名+SFZ(形成了一个联合主键),这样一来该用户数据的唯一性得到了验证。当然了,联合主键的场景不仅仅是这个,关键看业务场景。
从外包公司->创业公司->教育公司->现在所在公司,回过头来看过去我的数据表设计方面,存在的一个最大不足,即着重考虑技术实现难易层面,而轻视业务场景适用性、扩展性、稳定性等。