数据库唯一索引失效的7种场景与解决方案

1. 唯一索引失效的常见场景分析

当数据库表中出现明明已经创建了唯一索引却仍然产生重复数据的情况时，这通常意味着存在某些被忽视的边界条件或特殊场景。以下是几种典型情况：

1.1 NULL值的特殊处理

唯一索引对NULL值的处理是个经典陷阱。在大多数数据库系统中（如MySQL），唯一索引允许存在多个NULL值，因为NULL代表未知值，数据库无法判定两个NULL是否相等。

sql复制CREATE TABLE users (
    id INT PRIMARY KEY,
    email VARCHAR(255) UNIQUE  -- 允许插入多个NULL的email
);

注意：SQL标准对此没有统一规定，不同数据库行为可能不同。例如Oracle将NULL视为可比较的值，不允许重复NULL。

1.2 事务隔离级别的影响

在READ COMMITTED或更低隔离级别下，并发事务可能导致唯一约束被绕过：

1. 事务A检查某值不存在
2. 事务B也检查该值不存在
3. 两者都插入该值
4. 最终产生重复数据

解决方法是将事务隔离级别提升至SERIALIZABLE，或使用SELECT FOR UPDATE锁定检查。

1.3 索引未被实际创建

有时由于语法错误或权限问题，索引创建语句执行成功但索引并未实际生效。可通过以下命令验证：

sql复制-- MySQL
SHOW INDEX FROM table_name;

-- PostgreSQL
\d table_name

2. 字符编码与比较规则问题

2.1 大小写敏感性问题

当使用不区分大小写的排序规则时，可能产生意外重复：

sql复制CREATE TABLE products (
    code VARCHAR(50) COLLATE utf8_general_ci UNIQUE  -- 不区分大小写
);
-- 允许同时插入'ABC'和'abc'

解决方案是指定区分大小写的排序规则：

sql复制CREATE TABLE products (
    code VARCHAR(50) COLLATE utf8_bin UNIQUE  -- 区分大小写
);

2.2 空格和特殊字符处理

某些数据库会忽略字符串末尾空格：

sql复制-- MySQL中以下值在唯一索引看来是相同的
'value'
'value   '

3. 复合唯一索引的注意事项

3.1 部分列重复问题

复合唯一索引要求所有列的组合唯一，但允许部分列重复：

sql复制CREATE TABLE orders (
    user_id INT,
    product_id INT,
    UNIQUE (user_id, product_id)
);
-- 允许 (1,1), (1,2), (2,1) 但不允许重复的(1,1)

3.2 NULL值在复合索引中的影响

复合索引中只要有一列为NULL，该行就可能绕过唯一性检查：

sql复制-- 以下组合在多数数据库中都被允许
(NULL, 1)
(NULL, 1)

4. 数据库特定行为差异

4.1 MySQL的特殊情况

• MyISAM引擎：支持NULL值重复
• INSERT IGNORE：会静默忽略重复键错误
• ON DUPLICATE KEY UPDATE：可能掩盖唯一约束违反

4.2 PostgreSQL的独特行为

• 部分索引：可能意外限制唯一性检查范围

sql复制CREATE UNIQUE INDEX idx_partial ON users (email) 
WHERE active = true;  -- 非active用户email可能重复

5. 解决方案与实践建议

5.1 防御性编程策略

1. 应用层双重检查：

python复制# Python示例
with transaction.atomic():
    if not User.objects.filter(email=email).exists():
        User.objects.create(email=email)
    else:
        raise ValidationError("Email already exists")

2. 使用UPSERT操作：

sql复制-- PostgreSQL
INSERT INTO users (email) VALUES ('test@example.com')
ON CONFLICT (email) DO NOTHING;

5.2 索引设计最佳实践

• 明确处理NULL：CREATE UNIQUE INDEX idx ON table (col) WHERE col IS NOT NULL
• 对于业务上不允许NULL的列，加上NOT NULL约束
• 定期执行数据一致性检查：

sql复制-- 查找email重复的用户
SELECT email, COUNT(*) 
FROM users 
WHERE email IS NOT NULL
GROUP BY email HAVING COUNT(*) > 1;

6. 高级场景排查

6.1 分区表下的唯一约束

在分区表中，唯一索引必须包含所有分区键列，否则只能保证单个分区内唯一：

sql复制-- 错误的做法
CREATE TABLE sales (
    id SERIAL,
    region VARCHAR(50),
    UNIQUE (id)
) PARTITION BY LIST (region);

-- 正确的做法
CREATE TABLE sales (
    id SERIAL,
    region VARCHAR(50),
    UNIQUE (id, region)
) PARTITION BY LIST (region);

6.2 逻辑复制与同步延迟

在分布式系统中，复制延迟可能导致唯一约束暂时被绕过。可采用以下策略：

1. 使用全局序列生成器
2. 实现应用层的分布式锁
3. 最终一致性检查与修复机制

7. 性能与可靠性的平衡

唯一索引虽然能保证数据一致性，但会带来写入性能开销：

• 插入性能对比（测试数据）：

  记录数	无索引(ms)	有唯一索引(ms)
  1万	120	180
  10万	1,500	2,800

在需要高频写入的场景，可考虑：

• 定期批量处理+去重
• 使用消息队列实现异步校验
• 内存数据库作为缓冲层

我在实际项目中曾遇到一个案例：用户注册系统在高峰期出现重复邮箱，最终发现是由于NGINX重试机制导致请求重复提交。解决方案是在应用层增加幂等性令牌验证，同时将数据库隔离级别调整为REPEATABLE READ。这个教训让我明白，数据一致性问题往往需要全栈视角的综合解决方案。