到底需要加唯一索引不

文章目录

前言
一、逻辑删除、唯一索引一起使用（不推荐）
二、使用物理删除、并加唯一索引
使用逻辑删除，不加唯一索引

前言

唯一索引、逻辑删除，相信这两个词对于java程序员来说一点都不陌生吧。

唯一索引：索引列的值必须是唯一的，不允许重复
逻辑删除：用字段的状态记录数据是否被删除

最近项目上遇到因为没有正确使用这两个东西，导致一系列的问题。比如删除的时候逻辑删除，并且比如身份证号，手机号又加了唯一索引，再次保存就报错。有些项目从业务上来讲身份证，手机号必须唯一但是没有加唯一索引，但是产生了很多重复数据，今天就来分析一下什么场景下使用这两个东西。

一、逻辑删除、唯一索引一起使用（不推荐）

不建议一起用，除非项目开发前经过严格的设计讨论。逻辑删除的数据本身作为删除了的数据来说，不应该被业务逻辑中查询到（潜规则）。

加了逻辑删除之后，并且身份证号或者手机等字段加了唯一索引之后。这种情况的话在进行业务操作的时候，被逻辑删除的数据就要被我们业务代码查询出来了。比如我一个账号（手机号）已经被删除（逻辑）了，再次注册的话，直接报错就会因为有唯一索引而保存失败。因为已经物理删除的业务数据里面含有唯一索引的字段，重新走正常新增流程的时候时候就要考虑到这种情况。

除非已经被删除的数据，唯一索引的值不会再次从新增业务，这种场景还是可以加的。只是我很少遇到这种情况

二、使用物理删除、并加唯一索引

大多数的业务场景，都不会要求物理删除，并且有写字段的值有唯一性，比如账号的身份证，用户名、手机号等。如果我们这边表的数据状态比较多，并且业务比较复杂，和其他系统关联程度比较多。涉及新增编辑的业务非常多、数量量还非常大。这种情况就使用物理删除身份证加唯一索引。

为什么呢？
说一下我们公司的案例吧，现在我们公司的会员信息，有100万，这100万的数据来源口径非常多，估计得有近10个来源口径吧，口径都这么多了，维护的人就更多了，导致有些接口有并发问题，或者说是在维护数据时候又产生了脏数据。因为对于大部分公司来说，并发测试是做得不够的。所以想这种情况唯一索引就必须加上，避脏数据的产生，便于后期的数据维护。想要记录物理删除的数据，就用单独一个表记录吧。