看看pd的dashboard，上面有慢sql，执行计划如果有多个，可以直接绑定一个。如果只抓到了一个慢的，那就得自己绑定了。

日志确实看不到什么，如果一部署就有问题，那可能和cpu有点关系。

看看日志就行。 你现在的调用栈大概意思是： crash 启动后，recover 阶段，把wal应用后，写入 level0 层的文件，在计算crc32 看这个没啥用，可能是上层tikv自己退出的。看看上层tikv的日志，是不是有panic_mark 之类的。

修改完后你的tidb节点重启了吗？ 如果没有重启，看看tidb-operator的日志。 看看configmap改没改。

看看这个https://docs.pingcap.com/zh/tidb/stable/pd-recover/

有pd的数据吗?

检查慢sql吧，一个一个sql的 explain 执行计划里面有 cop 的就是下推到了 tikv 把这些慢sql优化掉就可以了

计算下推 https://docs.pingcap.com/zh/tidb/stable/expressions-pushed-down

和代码放一起用git管理

【简化技术栈是一个必然的趋势吗？】 必然趋势 【在使用 TiDB 过程中，有哪些优质的极简开发体验令你印象深刻？】 根本不用考虑资源规划，哪个组件cpu高扩哪个。

SHOW STATS_HEALTHY 如果以前也是全表扫描，那就试试 trace select xxxx 看看访问每个 region 用时多久。

全表扫描了 看看dashboard上面，关于这条sql有没有多个执行计划，是不是统计信息不准导致选择了一个错误的执行计划。 再看看表的健康度。

你是什么环境部署的呢？br是一个单独的工具，为什么会弄到8.5呢？换个低版本的就可以吧

这里看着写着br的版本是v8.5.1，应该得用同样的版本吧，br毕竟是物理备份。

【已落地或正在规划的AI 应用业务场景有哪些？用 TiDB 来支持过哪些 AI 业务 & 应用 ？】 内部有业务用了向量数据库，最终转到了 tidb 【目前你所在的企业数据类型有哪些？向量数据更倾向于存在向量数据库还是 TiDB 这种一体化数据库？】 不知道存的什么类型数据，他们一开始用了 milvus，后来转到了 tidb，用tidb主要是点查。

没问题。 rocksdb 是 一层一层的 sst 文件，blockcache 是缓存 sst 中的 index block，方便检索。

放心用，用了那么多版本了，有这问题的话早就出现了。 bloccache 是 rocksdb 的

sst 文件损坏了，这个tikv起不来了。幸好有3副本，缩掉重建就可以。 不过，如果你头铁，就非得要修好，也有办法: 用ldb工具，查这个sst对应的 cf、属于哪一层，对应的key的范围。 查这个范围对应的region，其中 不同的 cf 的 key 又有不同的前缀， 用 ldb 工具，unsafe 移除这个sst 用 tikv-ctl 工具，unsafe 移除对应的region的peer。 再启动就行了。这一片损失的数据就相当于删掉了。 以上是理论，我没这么修过。

可能是吧，也没仔细看是哪个时间点，我看s3上没有一点dump的文件，肯定不对。