用自增主键还是用多字段MD5做主键?(需要不重复约束)

发布于 2022-09-11 18:40:35 字数 463 浏览 38 评论 0

场景:

现有用户黑名单表, 需要身份证号和手机号联合确定唯一标识, 每天需要往里增量更新数据.
所以, 要求:
1) 查询时, 根据 身份证手机 能够快速查询.
2) 增量更新时要尽可能提高速度.

思路一:

我的思路是:
1) 设置自增主键. 自增主键的好处就是可以增加插入时的效率. 以为会减少主键索引树的分裂重建(Innodb引擎).
2) 身份证和手机号一起取md5, 设为唯一键, 作为唯一约束, 以方便sqoop导数据时根据该字段, 选择更新还是新插入.
这样的话, 起码要有四个索引: 主键, 身份证+手机号md5, 身份证号, 手机号.

思路二:

以前我的做法就是直接用 身份证+手机MD5 作为主键.

请大神指点, 哪种思路更优?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

金橙橙 2022-09-18 18:40:35

黑名单这种数据量不大没扩展需求的 找不到不用自增主键的理由?️

另外布隆过滤器是有误杀可能的……和这种手机身份证的黑名单业务就不是很适用

十二 2022-09-18 18:40:35

个人觉得模型可以这么设计:
1.DB层面,如果是单机模型,还是选用自增主键的方案,然后手机号和身份证号可以作为索引字段,可以考虑组合索引。如果是集群模型,选用雪花算法的主键。
2.Cache层面,如果是为了check黑名单的话,这里可以先采用布隆过滤器做第一步的拦截。如果布隆过滤器已经饱和,再去DB查询就好。

离旧人 2022-09-18 18:40:35

推荐自增主键,
MD5导致乱序插入,而且太长,影响二级索引。
要保证唯一性,身份证+手机号建唯一索引,
如果还需要根据身份证或手机号的单一条件查询,身份证从存储的角度比手机号长很多,额外建一个手机号的索引就可以了。而身份证的谓词条件可以用到上面唯一索引的最左前缀匹配。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文