告别数据重复：TiDB唯一索引守护业务数据一致性
项目地址: https://gitcode.com/GitHub_Trending/ti/tidb 你是否曾因订单编号重复导致财务对账混乱？或因用户邮箱重复引发登录异常？在分布式数据库中，保证数据唯一性比单机数据库更具挑战。TiDB 作为分布式关系型数据库，通过唯一索引（Unique Index）机制为业务数据一致性提供坚实保障。本文将从使用场景、实现原理到最佳实践，全面解析 TiDB 唯一索引的设计与应用。
一、唯一索引：分布式环境下的数据唯一性守护者
1.1 什么是唯一索引？
唯一索引是数据库约束机制的核心组件，它确保索引列的值不重复（NULL 值除外，可存在多个 NULL）。在 TiDB 中，唯一索引分为两类：
- 主键索引（Primary Key）：表的强制唯一标识，默认自动创建
- 唯一二级索引（Unique Secondary Index）：用户手动创建的非主键唯一约束
官方定义：TiDB 唯一索引通过键值对结构实现，其中唯一索引键格式为
t | {table_id} | _i | {index_id} | {index_column_values}，值存储行标识（Handle）docs/design/2020-05-08-cluster-index.md
1.2 业务痛点解决方案
| 痛点场景 | 唯一索引解决方案 | 示例 SQL |
|---|---|---|
| 电商订单编号重复 | 创建唯一索引确保订单号全局唯一 | CREATE UNIQUE INDEX uk_order_no ON orders(order_no) |
| 用户邮箱重复注册 | 对邮箱列添加唯一约束 | ALTER TABLE users ADD UNIQUE INDEX uk_email(email) |
| 商品 SKU 编码冲突 | 联合唯一索引保障多维度唯一性 | CREATE UNIQUE INDEX uk_sku_category ON products(sku, category_id) |
二、TiDB 唯一索引的实现原理
2.1 分布式架构下的唯一性挑战
传统单机数据库通过锁机制在单节点内保证唯一性，而 TiDB 采用分布式架构，数据分散存储在多个 TiKV 节点。其面临两个核心挑战：
- 跨节点数据同步：确保不同节点的索引数据一致
- 高并发写入冲突：多节点同时写入相同值时的冲突检测
2.2 底层存储结构解析
TiDB 唯一索引采用 Key-Value 键值对存储，结构如下：
t | {table_id} | _i | {index_id} | {index_column_values} // 键
{handle} // 值（行标识）
技术细节：与非唯一索引相比，唯一索引键中不包含 Handle 后缀，直接通过索引值定位行数据，减少一次查找开销 docs/design/2020-05-08-cluster-index.md
2.3 两阶段提交保障一致性
TiDB 通过分布式事务的两阶段提交（2PC）实现唯一索引的跨节点一致性：
- 预提交阶段：检查所有涉及节点的索引唯一性
- 提交阶段：确认无冲突后提交索引变更
三、创建与管理唯一索引
3.1 基本语法
创建表时定义唯一索引：
CREATE TABLE users (
id INT PRIMARY KEY,
email VARCHAR(255) NOT NULL,
username VARCHAR(50) NOT NULL,
UNIQUE INDEX uk_email (email),
UNIQUE INDEX uk_username (username)
);
为现有表添加唯一索引：
ALTER TABLE orders ADD UNIQUE INDEX uk_order_sn (order_sn);
3.2 联合唯一索引
当需要多列组合唯一时，可创建联合唯一索引：
CREATE TABLE product_inventory (
id INT PRIMARY KEY,
product_id INT NOT NULL,
warehouse_id INT NOT NULL,
quantity INT NOT NULL,
UNIQUE INDEX uk_product_warehouse (product_id, warehouse_id)
);
上述索引确保同一商品在同一仓库只有一条记录
3.3 在线 DDL 特性
TiDB 支持唯一索引的在线创建，不阻塞读写：
ALTER TABLE users ADD UNIQUE INDEX uk_phone (phone) ALGORITHM=INPLACE LOCK=NONE;
优势：相比 MySQL，TiDB 的在线 DDL 不会导致长时间表锁定，适合生产环境频繁变更 官方文档
四、性能优化与最佳实践
4.1 选择性与索引长度
唯一索引列应具有高选择性（即值分布稀疏）。对于字符串类型，可指定前缀长度平衡唯一性与性能：
CREATE UNIQUE INDEX uk_email_prefix ON users (email(10));
注意：前缀索引可能导致全表扫描，仅在确知前缀足够区分唯一性时使用
4.2 避免过度使用唯一索引
唯一索引会增加写入开销，建议：
- 仅对必要列创建唯一索引
- 避免在频繁更新的列上创建唯一索引
- 考虑业务层去重减少数据库压力
4.3 冲突处理策略
当唯一键冲突发生时，TiDB 会返回 Duplicate entry 错误。应用层可采用以下策略：
- 重试机制：适用于随机生成的唯一键（如订单号）
- 业务排队：通过消息队列序列化写入
- 预检查：插入前先查询是否存在
示例冲突处理代码：
public boolean saveUser(User user) {
try {
return userMapper.insert(user) > 0;
} catch (DuplicateKeyException e) {
log.warn("用户邮箱已存在: {}", user.getEmail());
// 业务处理逻辑
return false;
}
}
五、监控与维护
5.1 索引使用监控
通过 TiDB 监控面板关注以下指标：
tidb_index_scan_total：索引扫描次数tidb_unique_constraint_violations：唯一约束冲突次数tikv_region_leader_count：索引数据分布均衡性
5.2 定期检查与优化
使用 ANALYZE TABLE 更新统计信息，帮助优化器选择最优索引：
ANALYZE TABLE users;
查询索引使用情况：
SELECT * FROM information_schema.tidb_index_usage WHERE table_name = 'users';
六、总结与展望
TiDB 唯一索引通过分布式事务和键值存储机制，在保证数据唯一性的同时兼顾性能。合理使用唯一索引需遵循：
- 明确业务唯一性需求，避免过度设计
- 优先使用主键索引，其次考虑唯一二级索引
- 联合索引注意列顺序，高频过滤列前置
- 监控索引使用情况，定期优化
随着 TiDB 持续发展，未来唯一索引将支持更多高级特性，如部分唯一索引、延迟约束检查等，进一步提升分布式场景下的数据一致性保障能力。
扩展阅读：
关注 TiDB 技术社区，获取更多数据库性能优化技巧！如有疑问或经验分享，欢迎在评论区留言讨论。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
