数据库备份还原后，用全局索引查询时报数据不一致

TiDBer_LQYQ8lAQ · 2026 年6 月 4 日 07:50

【TiDB 使用环境】测试环境
【TiDB 版本】v8.5.6
【BR版本】v8.5.6
【部署方式】虚拟机
【遇到的问题：问题现象及影响】
通过BR工具对TIDB数据库进行备份还原后，用全局索引查询时会报数据不一致，报错信息如下：

SQL 错误 [8133] [HY000]: data inconsistency in table: AliExpressOrderItem, index: IDX_AliExpressOrderItem_Globa, index-count:1 != record-count:0

查询语句如下，在order_id字段上创建了全局索引：

SELECT * from  Order_Test.AliExpressOrderItem
WHERE  order_id='8122954138504196'

用以下两个语句检查的时候都没有问题

ADMIN CHECK TABLE AliExpressOrderItem
ADMIN CHECK INDEX AliExpressOrder IDX_AliExpressOrder_Globa

请问这是什么原因？

wbslxw · 2026 年6 月 4 日 07:59

全局索引（Global Index）BR 备份还原逻辑缺陷，局部索引 KV 与行数据 KV 数量不匹配（索引多 / 缺行、缺索引行），ADMIN CHECK 全量校验无异常，但单点条件命中该脏数据行时触发一致性校验报错

mtmt · 2026 年6 月 4 日 08:09

ALTER TABLE … REBUILD GLOBAL INDEX重建异常全局索引；
后续备份前等待全局索引后台合并任务完成再执行 BR。

TiDBer_LQYQ8lAQ · 2026 年6 月 4 日 12:09

这种bug怎么一直没有修复啊，有什么方法可以解决吗？

TiDBer_LQYQ8lAQ · 2026 年6 月 4 日 12:12

ALTER TABLE … REBUILD GLOBAL INDEX
这样重建索引会报语法错误，先删除再创建是可以，不过表比较大，服务器的配置又比较低，重新创建一个大表的索引十几二十个小时。

TiDBer_AHjy0eKV · 2026 年6 月 4 日 22:21

应该是BR 恢复后全局索引中残留了孤儿索引记录

菩提老祖 · 2026 年6 月 5 日 00:24

孤儿索引键（dangling / orphan index key）——全局索引里有一条 order_id='8122954138504196'的索引记录，指向某一行的 handle，但你顺着那个 handle 去找行数据时，那行数据已经不在了。索引悬空了。
重建索引，或者ADMIN RECOVER INDEX修复索引

TiDBer_bgWIGhji · 2026 年6 月 5 日 01:31

从 MySQL 迁到 TiDB，如果原来用了自增主键，高并发下会产生写入热点，因为所有写操作都集中在同一个 Region。建议评估下改成 AUTO_RANDOM 或者业务自己生成分布式ID，利用 TiDB 的 Region 自动拆分机制提高写入吞吐。

独善其身 · 2026 年6 月 5 日 02:32

BR 恢复全局索引 (GLOBAL INDEX) SST 重写异常，残留孤立全局索引 KV、行记录 KV 被彻底抹除；ADMIN CHECK 全表 / 全索引无报错、单点条件查询报 8133 是全局索引独有的校验逻辑差异

TiDB001 · 2026 年6 月 5 日 02:49

检查索引IDX_AliExpressOrderItem_Global的状态是否完好。如果索引损坏，你可以尝试重建索引

TiDBer_LQYQ8lAQ · 2026 年6 月 5 日 06:55

不是只有一行数据有问题，而是随便一行数据都有问题，数据库里有40个表建了全局索引，40个表都有问题，应该不是简单的孤儿索引键的问题。如果只能通过后期修复，感觉不太靠谱啊

TiDBer_LQYQ8lAQ · 2026 年6 月 5 日 07:11

感觉不像只是残留，好像整个索引都有问题，随便查一个值都有问题。
这个是用BR恢复的时候重写异常吗？还是在备份的时候就已经异常了？怎么避免这样的异常呢？

TiDBer_LQYQ8lAQ · 2026 年6 月 5 日 07:12

检查是没有问题的，但查询有问题

BI小z · 2026 年6 月 5 日 08:03

先执行统计刷新，无效则删索引重建

TiDBer_lPQGLonR · 2026 年6 月 5 日 10:14

删全局索引，重新CREATE GLOBAL INDEX重建；

大唐天子 · 2026 年6 月 6 日 01:05

语法问题：TiDB 不支持通过 ALTER TABLE REBUILD GLOBAL INDEX 重建全局索引，该语句执行报错；
可行方案：仅支持先删除原有全局索引，再重新建立；
痛点：大表 + 低配服务器环境下，新建索引耗时漫长，动辄十几、二十小时。

TiDBer_bgWIGhji · 2026 年6 月 6 日 01:32

TiDB 的兼容性跟执行计划的生成机制有关，同样的 SQL 在 MySQL 和 TiDB 上的优化器决策可能不同，特别是子查询和 JOIN 的处理方式。迁移前建议用 SQL Plan Management 做下 SQL 兼容性扫描。

TiDB_001 · 2026 年6 月 17 日 01:58

备份前等待全局索引后台合并任务完成，避免备份时索引数据异常

狂拽瘸子好腿 · 2026 年6 月 17 日 02:38

大概率是 BR 还原后全局索引的 Region 数据未完成异步修复 / 分裂迁移，或索引统计元数据快照与实际物理数据存在短时偏差，一致性校验命令仅做静态快照检测没触发实时检索所以未告警。

TiDBer_bgWIGhji · 2026 年7 月 1 日 11:00

备份还原后全局索引不一致，建议用BR的checksum校验功能检查数据一致性。也可以重建索引试一下。