你把程序调用的结果返回单独保存到一个文件就可以看到了

select * from mysql.tidb 看下

业务没变化的话，盲猜是你这个表相关的sql 执行计划变了，比如本来是索引扫描，因为一些情况执行计划变成了全表扫描，所以从热力图上看上去读流量变大了。‘ 从读取次数看下和升级前变化大不大？ 按process_key， total_key 倒排查一下这张表相关sql ，看下有没有执行计划变化的 grafana 监控看下 tikv 有没有热点 top sql 页面观察下升级前后对比

日志里面搜 “progress” 试试看

慢查询和sql语句分析都看不到 热力图上显示的那张表吗？ 看下这个是不是有帮助 ：专栏 - Dashboard 热力图显示不准？ 如何定位热点相关sql ？ | TiDB 社区

现在问题解决了吗？

先升级到 v5.4.3 试试吧

tikv 资源是不是爆了？ 或者说有热点？ tikv cpu 使用率的截图发下看看

实验特性，不建议在生产上使用

是的，edit-config 改

7.1 默认是不清理的， 你按需要改成想保留的天数就行了， v5.4以下的版本，raftdb的日志还没合并到 max-days 这个参数里面来，所以还是用 raftdb.info-log-keep-log-file-num 去设置

v5.4 以后的版本这两个参数已经废弃了 ，统一由 log.max-days 参数控制。

偶发还是所有sql都慢了？ 看下具体执行信息 是不是 coprocessor time 很高？

可以收集火焰图看下

这是 oom 了呀， 可以参考文档配置下相关参数 tidb ： https://docs.pingcap.com/zh/tidb/v8.0/configure-memory-usage#tidb-内存控制文档 tikv ： https://docs.pingcap.com/zh/tidb/stable/tune-tikv-memory-performance#tikv-内存参数性能调优

数据量小的话直接 select into outfile 就可以 https://docs.pingcap.com/zh/tidb/stable/sql-statement-select#select--into-outfile 数据量大还是用 dumpling 导出吧

我要挑战

[image] 你这不是把加索引的操作过滤了吗？

可以根据告警时间点的监控确认下是不是误报， 监控位置 ： tikv-details - resove-ts