为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：v4.0.0-rc
- 【问题描述】：我们测试环境从3.0.8 升级到4.0.0-rc 应用端捕捉到inconsistent extra index idx_name, handle 300039 not found in table 错误。
你好，
- 此报错信息如果是 tidb.log 中出现的，烦请上传下完整日志
- 由于 tidb 数据文件和索引文件是分开存储的，所以麻烦确认该 handle 是否在索引文件和数据文件中都存在。
你好，第二个应该怎么查询呢
非tikv.log 出现，由应用端异常捕获到的
你好，
如果是应用端捕捉，烦请配合提供以下信息
- 阐述下目前造成的影响，
- 上传下 log/tidb.log ，包含报错时间点。
你好，
1、 请上传下脱敏的表结构，
2、 烦请确认日志中的语句是否可在 mysql -uroot -p -P4000 -h192.168.xx.xxx 中正常反馈，
CREATE TABLE a (
a bigint(20) NOT NULL,
CreateTime datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (a,CreateTime),
UNIQUE KEY SendOrderId (a),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
可以使用，我这边有详细问过开发，他这个错误好像是一个事务里，先update 在select 最后提交
但是我感觉好像不像他的流程写法的问题，会不会拓扑导致的。我测试环境的拓扑图中tikv 节点只有两个，tikv 的副本数也设置的是2 。
你好，
和拓扑没有硬性联系，你这边麻烦将日志中的语句执行看下是否有结果并将其 explain 也截全图出来看下，
Hi @tonyhu214 ，请问 SQL 中，是否有类似 update a, (select … from …) s set … 这样的语法？该问题有可能是 4.0-RC 的一个已知 bug 导致的。
- 对于表，首先请使用
admin check table a确认下是否报错：如果报错，说明发生了数据/索引不一致的 bug。 - 请尽量升级到 4.0-RC.1 版本。
还请首先确认上述问题，我们会继续跟进。
确认过没有上述写法，admin check table 都成功
我这边升级到rc1 看下 tiup 的版本号是v4.0.0-rc.1 吗？
暂时好像未见，打算明天再看看，这个bug 好像极难测出来。语句的话是这样的update table set a = xxx where index_column = xxxx; 确认过筛选的值，更新的值的类型 与其对应的字段类型相同
OK，既然 admin check table 成功，说明表的数据是没有问题
注意到您的日志中包含了 ‘set transaction_isolation=READ-COMMITTED’，即设置了 RC 隔离级别，该错误可能与这个相关。当然目前只是猜测，我们会尽快尝试确认。
我这边升级到rc1 看下 tiup 的版本号是v4.0.0-rc.1 吗？
是这样的，RC.1 是一个更加稳定的版本，建议您升级．
我们基本可以确定，该问题与 RC 隔离级别读的一个已知 Bug 有关，升级到 v4.0.0-rc.1 或 v4.0.0-rc.2（预计今日发布）可以得到解决。
请注意，TiDB 4.0 在悲观事务模式下支持了 RC 隔离级别，通过您提供的日志，我们发现 RC 被启用了（3.0 版本中 ‘set transaction_isolation=READ-COMMITTED’ 会被忽略）：RC 隔离级别相关文档说明
这意味着，在您升级到 TiDB 4.0 时，读相关的语义有一定的变化，这一点也请关注。
链接 404 了
更新了，可以看下。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。