【TiDB 使用环境】生产环境 /测试/ Poc
【TiDB 版本】
【操作系统】
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
报错信息：[Err] 9004 Resolve lock timeout。基本情况：测试环境，没有任何事务，研发已经将所有应用停止，进程上也看不到任何应用的进程，没有函数存储过程。
报错情况：有个表不知道是数据损坏了还是怎么了，查询就报错，报错信息如图，更详细情况是查询到扫描到某条数据就报错，不查这条数据就没问题，但是由于查不了这条数据，所以也不知道这条数据是什么情况。
请帮忙看看是什么原因，不然无法上生产
可目前没有任何并发，在没有任何进程，应用全停的情况下，就我单独执行一个sql语句也会报错
resolve lock是由gc触发的，并不是由事务触发的
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview/#resolve-locks清理锁
不行，SET GLOBAL tidb_gc_enable = off;，我即便关闭gc，他还是一样
重启试试
重启也许可以，重建表应该也可以，但是查不出什么原因是不行的，至少得知道是什么操作或者什么原因导致的，不然，这没法上生产，因为到时候生产出现，我重建表却无法用这个表的数据导数据，这去哪里找数据源，高可用的backup可能是同步了同样的问题，可能从库也是select不了这个表数据，那就无解了
在 无事务、无应用连接的测试环境 中，对某张表查询时 扫描到特定数据行时出现 [Err] 9004 Resolve lock timeout 错误，高度怀疑是 数据损坏问题导致查询失败，先查查硬件是不是有IO块错误，逻辑错误或者物理坏道了？
各位大佬支个招，现在怎么解决反而没那么重要，是什么原因导致，或者什么操作会导致这种结果？这是最重要的，毕竟是测试环境，我知道什么操作导致的，我生产避免这种操作就行了 
可以尝试将连接这个数据库的服务都关闭掉试试
做过 admin check 么？check一下看看，按表结构来说，那个where条件会走索引。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-admin-check-table-index/#admin-check-tableindex
不行呢，只要扫描到那条数据就报错的，这命令要扫描
那大概率就是数据损坏了。或者不通过主键、索引能查出来那条数据么？
今天遇到了同样的问题，还没有准确定位，（准确定位问题难度较大，还在尝试）。目前我怀疑我的问题是，前面有事务异常了，我insert … on duplicate key update … 涉及到了前面异常事务残留的锁没有及时 resolve，所以报错。等了一段时间，残留的 lock 被gc 处理了，就能正常insert 了。
目前没有并发不能排除并发导致的问题，这个问题是前面并发高的时候留下的，后面并发降低或者说消失了，问题还在。主要是看怎么解决和避免。
