TiDB分区表合并操作导致主键重复问题分析

问题背景

在分布式数据库TiDB中，当对分区表执行合并分区(COALESCE PARTITION)操作时，如果同时伴随网络分区故障，可能会导致表中出现主键重复的数据行。这种现象在TiDB 8.5.1版本中仍然存在，表现为admin check table命令报错，查询结果中出现相同主键的多条记录。

问题复现场景

该问题在以下特定条件下出现：

1. 表结构为分区表，使用非聚簇主键
2. 并发执行事务负载和分区合并DDL操作
3. 在操作过程中注入网络分区故障
4. 故障恢复后完成剩余操作

具体表现为：

• 执行admin check table时报错，提示数据不一致
• count(*)返回正确行数，但实际查询结果包含重复主键行
• 表中出现相同主键值的多条记录

技术原理分析

分区表合并操作机制

TiDB中的COALESCE PARTITION操作会将指定数量的分区合并到其他分区中。在内部实现上，这涉及到：

1. 创建新的分区结构
2. 将数据从旧分区迁移到新分区
3. 验证数据一致性
4. 提交元数据变更

问题根源

问题的核心在于非聚簇主键表在分区重组时的处理逻辑：

1. 对于非聚簇表，TiDB会使用隐藏的_tidb_rowid作为实际存储的键
2. 在分区重组过程中，系统会重新生成_tidb_rowid值
3. 当并发修改与重组操作交织时，可能导致：
   • 同一主键记录在不同分区中存在不同版本
   • 重组后无法正确合并这些版本
   • 最终产生主键重复但其他列不同的记录

网络分区的影响

网络分区加剧了这一问题，因为它可能导致：

1. 部分节点无法及时收到DDL操作
2. 事务在不同节点上产生分歧
3. 恢复后合并操作无法正确处理冲突

解决方案建议

针对这一问题，可以从以下几个方向考虑解决方案：

1. DDL执行优化：在分区重组操作期间加强锁机制，防止并发修改
2. 冲突检测机制：在合并数据时增加主键冲突检查
3. 事务一致性保证：改进网络分区恢复后的数据一致性处理
4. 错误处理：当检测到潜在冲突时，提供更明确的错误信息

开发者测试用例

以下是一个简化的测试用例，可用于验证修复方案：

func TestPartitionMergeWithConcurrentUpdate(t *testing.T) {
    // 初始化测试环境
    store := testkit.CreateMockStore(t)
    tk := testkit.NewTestKit(t, store)
    tk.MustExec("use test")
    
    // 创建分区表
    tk.MustExec("create table t (a int primary key nonclustered, b int) partition by hash(a) partitions 2")
    tk.MustExec("insert into t values (1, 1)")
    
    // 模拟并发更新
    testfailpoint.EnableCall(t, "github.com/pingcap/tidb/pkg/ddl/afterRunOneJobStep", func(job *model.Job) {
        if job.SchemaState != model.StateDeleteReorganization {
            return
        }
        tk2 := testkit.NewTestKit(t, store)
        tk2.MustExec("use test")
        tk2.MustExec("update t set b = 2 where a = 1")
    })
    
    // 执行分区合并
    tk.MustExec("alter table t coalesce partition 1")
    
    // 验证数据一致性
    tk.MustExec("admin check table t")
    tk.MustQuery("select * from t").Check(testkit.Rows("1 2"))
}

总结

TiDB分区表在特定条件下的合并操作可能导致主键重复问题，这反映了分布式环境下DDL操作与数据一致性保障的复杂性。理解这一问题的机理有助于开发者更好地设计分区表使用方案，也为TiDB核心团队提供了改进方向。建议用户在关键业务场景中谨慎使用分区表合并操作，并关注后续版本对此问题的修复。