数据库唯一性约束与业务主键对防止数据覆盖的安全价值

数据库里最让人后背发凉的事情，莫过于一条UPDATE语句执行完，发现原本正确的数据被错误覆盖了，而且还没法回滚。这种事故在并发高的业务系统里几乎每天都在上演。很多人以为这是代码逻辑的Bug，实际上，真正能在底层防住这类低级错误的，是数据库的唯一性约束和合理的业务主键设计。它们不是简单的技术细节，而是数据安全的物理防线。

应用层做防重几乎是所有开发者的第一反应。先查一次，有就更新，没有就插入。这种逻辑在单线程下完美运行，一旦放到高并发环境，两个请求同时查到“不存在”，然后先后执行插入，后一条就把前一条覆盖了。这不是代码写错了，是检查与写入之间存在时间差。数据库的事务隔离级别只能保证读取的一致性，管不了两个事务都认为自己该写入的场景。真正能堵死这条路的，只有数据库层面的唯一性约束。它不依赖时间差，不依赖业务逻辑判断，只要索引树里已经存在同样的键值，第二个写入操作直接报错，没有任何商量余地。

很多产品经理觉得加唯一性约束会限制业务灵活性，这种想法很危险。唯一性约束本质上是在数据库里用最硬的规则把业务含义固定下来。比如用户表里，登录名必须唯一，这不仅仅是技术上的索引，而是业务上“一个登录名只能对应一个用户”这条铁律的物理化表达。如果没有这个约束，哪天批量导入脚本出了问题，或者接口被人重放攻击，数据库会默默接受重复数据，然后业务逻辑开始错乱，订单挂到别人名下，资产计算翻倍，这些问题修复起来比加约束痛苦一百倍。把业务规则写在应用代码里，相当于把法律条文写在沙滩上；写在数据库约束里，才是刻在石头上。

几乎所有表都有一个自增ID做主键，这是工程上的惯性思维。但自增ID是给数据库内部用的，跟业务毫无关系。真正决定数据唯一性的是业务主键，它可能是一个字段，也可能是多个字段的组合。订单表的业务主键可能是“订单号”，交易流水表的业务主键可能是“渠道加渠道流水号”。自增ID保证每行数据有个物理地址，业务主键保证同一笔业务不会出现两份记录。两者职责不同，不能互相替代。实践中出问题的，往往是只有自增ID、没有业务主键的表。程序每次插入都生成新ID，数据库从不报错，重复数据就这样悄无声息地堆积起来。

单字段唯一约束好理解，但真实业务里唯一性往往由多个条件共同决定。一个用户在一个活动里只能领一次券，这个唯一性由“用户ID加活动ID”共同构成。一个商户在一个平台只能有一个生效中的合同，这个唯一性由“商户ID加平台类型加状态”构成。这种场景必须建联合唯一索引，而不是在应用层做判断。联合索引的字段顺序也很讲究，把区分度高的字段放前面，查询和插入性能都会更好。还有一点容易被忽视，联合唯一索引里如果包含可为空的字段，空值的处理逻辑在不同数据库里不一样，MySQL里多个NULL值被视为不相等，这意味着允许插入多条NULL，这个坑踩过的人不在少数。

唯一性约束建立之后，插入重复数据会直接报错，但很多业务场景需要“存在就更新、不存在就插入”，也就是常说的UPSERT。MySQL提供了INSERT ON DUPLICATE KEY UPDATE语法，这个功能用好了是利器，用不好就是数据覆盖的帮凶。关键点在于，这条语句在遇到唯一键冲突时，会用UPDATE子句里的值覆盖已有行的指定字段。如果你在UPDATE里把创建时间、原始金额、来源渠道这些不该变的字段也更新了，那就是一次合法的数据破坏。正确的做法是，UPDATE子句里只写那些应该被新值覆盖的字段，比如更新时间、状态、最新金额等。不变字段坚决不写进UPDATE部分，这样即使并发冲突，也不会丢失原始信息。

-- 正确示例：只更新可变字段
INSERT INTO order_summary (order_no, amount, status, created_at, updated_at)
VALUES ('ORD001', 100.00, 'paid', NOW(), NOW())
ON DUPLICATE KEY UPDATE 
    amount = VALUES(amount),
    status = VALUES(status),
    updated_at = NOW();
-- 注意：created_at 不在 UPDATE 子句中，原始创建时间不会被覆盖

单库单表的唯一性约束好解决，分库分表之后就麻烦了。数据库的唯一索引只能管自己这个分片，跨分片的唯一性它无能为力。这时候业务主键的设计就变得至关重要。如果业务主键本身能保证全局唯一，比如用雪花算法生成的分布式ID，或者用业务维度组合出的天然唯一键，那么即使数据分散在不同分片，也不会出现两条相同业务含义的记录。另一种思路是在分片键上做文章，把需要保证唯一性的字段作为分片键，让相同值的数据必然落到同一个分片，这样分片内的唯一索引就能继续发挥作用。两种方案各有利弊，前者依赖ID生成算法的可靠性，后者可能导致数据倾斜，需要根据业务量级和访问模式来权衡。

有人担心建太多唯一索引会影响写入性能，这个担心合理但不该成为不建约束的理由。每次INSERT或UPDATE涉及唯一索引字段时，数据库确实需要检查索引树里是否已存在该值，这个检查有成本。但这个成本相比数据出错后的修复成本，完全可以接受。真正需要优化的是索引字段的选择，不要在太长的字符串字段上建唯一索引，可以用该字段的哈希值建一个辅助列，在哈希值上建唯一索引，同时保留原始字段用于查询。另外，联合唯一索引的字段数量不要太多，三到四个字段是常见上限，再多就要重新审视业务模型是否合理了。

业务主键怎么选，直接影响数据防覆盖的能力。最理想的情况是业务本身就带有天然唯一标识，比如身份证号、统一社会信用代码、国际标准书号。这些外部权威机构颁发的编码，唯一性有保障，直接拿来用最省心。但大多数业务场景没有这种天然标识，需要自己设计。设计时避免使用时间戳加随机数这种碰撞概率虽低但理论上不绝对的方案，更要避免用业务状态会变化的字段做主键，比如手机号、邮箱，这些字段可能被回收或转移，一旦变了，所有关联数据都要跟着动。推荐的做法是，业务主键由固定的业务维度组合而成，这些维度在数据创建时就确定，终身不变。比如交易流水，用“支付渠道代码加渠道返回的流水号”，这两个值一旦产生就不会改变，组合起来就是稳固的唯一键。

线上数据出问题需要批量修复时，唯一性约束的保护价值会被放大。DBA或开发人员写数据修复脚本，经常是直接写UPDATE或INSERT语句，没有经过正常业务流程的校验。如果没有唯一约束，一条写错WHERE条件的UPDATE可能把整表数据改得面目全非，或者重复插入大量脏数据。有唯一约束在，至少重复插入会直接报错，把影响范围控制住。建议在数据修复的SQL脚本里，除了依赖唯一约束，还要显式使用事务，并且在UPDATE之前先SELECT出受影响的行数和样本数据，确认无误再提交。约束是最后一道防线，前面的流程规范同样重要。

现在大部分项目都用ORM框架操作数据库，框架提供的saveOrUpdate之类的方法看起来很智能，实际上隐藏了风险。这些方法通常先查一次，根据查询结果决定insert还是update，这个逻辑跟我们手写代码的问题一样，在高并发下不靠谱。更危险的是，有些ORM的save方法默认行为是，如果实体对象里有主键值就执行update，没有就insert。一旦代码里不小心给实体设置了已存在的主键值，本该插入的新数据变成了更新操作，直接覆盖了原有记录。解决办法是，在实体类上明确标注业务键字段，让ORM基于业务键来判断唯一性，而不是依赖自增主键。同时，对于关键的写入操作，尽量写原生SQL，把控制权拿回来。

唯一约束建好了不是万事大吉，还要监控它什么时候被触发。正常业务流程不应该频繁触发唯一约束冲突，如果监控到Duplicate entry错误量突然飙升，要么是业务逻辑有Bug在疯狂重试，要么是有人在恶意重放请求，要么是上游系统重复推送了相同数据。无论哪种情况，都需要立刻介入。可以在应用层捕获数据库返回的唯一约束冲突错误码，记录详细的上下文日志，包括冲突的键值、请求来源、时间戳等，然后触发告警。这个监控数据本身就是业务健康度的重要指标。

数据库的唯一性约束和业务主键设计，说到底是对数据完整性的一种敬畏。它们不会让系统跑得更快，也不会让代码看起来更高级，但能在最底层守住数据质量的底线。应用层的校验可以绕过，ORM的封装可以骗过，但数据库索引树里的那层物理约束，是任何并发请求都绕不开的硬关卡。把业务规则写进数据库结构里，不是过度设计，是成熟工程师对生产环境最基本的尊重。