唯一约束能否防止数据篡改

这是一个非常好的问题。简短的回答是：不能直接防止。

唯一约束（Unique Constraint）的核心目的是保证数据唯一性，而不是保证数据不被篡改。下面从几个层面详细解释：

一、唯一约束是做什么的？

唯一约束的作用：

• 确保某一列或一组列的值在表中是唯一的
• 防止重复插入或重复更新导致冲突

✅ 防止的是：

• 插入一条已经存在的数据
• 把某条记录更新成其他已经存在的值

❌ 不防止的是：

• 合法修改一条记录的值（只要不违反唯一性）

二、为什么说“不能防止数据篡改”？

示例

CREATE TABLE user (
  id INT PRIMARY KEY,
  email VARCHAR(255) UNIQUE
);

当前数据：

合法修改（唯一约束不会阻止）

UPDATE user SET email = 'b@b.com' WHERE id = 1;

✅ 完全允许
❌ 但这就是一种“数据篡改”场景

唯一约束 不会检查：

• 谁修改的
• 什么时候修改的
• 修改前后是否“合理”

三、唯一约束只能防止“重复”，不是“防篡改”

可以把唯一约束理解为：

守门员（只管重复），而不是 防盗门（不管谁进、怎么进）

即使有唯一约束：

• 有写权限的账户
• 恶意 SQL
• 逻辑漏洞
  都可以改数据

四、真正能防止或发现数据篡改的手段

1️⃣ 权限控制（最基础）

GRANT SELECT ON table TO app_user;
-- 不给 UPDATE / DELETE

2️⃣ 审计日志（最常见）

• 记录：
  • 谁改的
  • 改了什么
  • 改之前的值 / 改之后的值
  • 时间

方式：

• 触发器（Trigger）
• 应用层日志
• 数据库审计功能（Oracle Audit、MySQL Enterprise）

3️⃣ 不可变 / 追加式设计（防篡改）

例如：

orders
orders_history

• 只追加
• 不 UPDATE、不 DELETE
• 历史可回溯

4️⃣ 校验字段（防事后篡改）

hash = SHA256(id || email || create_time)

• 存储一行数据的“指纹”
• 篡改后 hash 对不上

常用于：

• 金融数据
• 关键业务日志
• 区块链风格设计

5️⃣ 数据库层面的防护

• 触发器阻止非法 UPDATE
• 行级安全（PostgreSQL RLS）
• 只读副本 / 审计表
• 数据签名 / 数字摘要

五、总结对照表

一句话总结

唯一约束只能防止“重复数据”，不能防止“数据被修改”。
防篡改是一个综合设计问题，不是单一约束能解决的。

如果你愿意，可以告诉我：

• 使用的是 MySQL / PostgreSQL / Oracle / SQL Server
• 想防的是 误改 / 恶意改 / 审计合规

我可以帮你给出更具体的设计方案。