为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
附件中是我在其中的一台TiDB CPU 100%状态下通过debug接口获取到的debug信息，请帮忙看一下是什么问题，我对go不太了解。
debug.zip (3.1 MB)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
好的，我试一下
好的，有问题再反馈
这个慢日志的查询是不是有问题，我把慢查询日志清理到之后执行的还是很慢
3.如果查看后没有方向，可以反馈下这段时间的监控信息
三台机器清理完历史慢查询日志只保留当前慢查询日志（大小100-200M），然后从客户端连上TiDB执行查询select * from slow_query limit 10; 无响应，Dashboard系统的慢查询页面也加载不出来慢查询。有一台执行查询的TiDB CPU从不到20%涨到接近100%，不确定是否是前面的查询造成的，kill调slow_query表的查询后CPU也没有下降。
刚发现CPU升到接近100%的那台TiDB还有10月份的100多个日志文件没删掉，大约30多个G。其他的两台TiDB上文件不多，容量大约1G左右。
清掉所有的历史慢查询日志之后客户端执行select * from slow_query limit 10;这个查询仍然没有响应，Dashboard系统的慢查询页面可以显示慢查询列表了。
这个查询还是查不出来是吧？ 麻烦跑这个查询时，再拿下这个 tidb 的 debug 信息吧
在CPU飙升的那台服务器上，上面的SQL经过907秒后执行完成了，现在CPU也恢复到20%左右了，我又执行了一次查询，抓了debug信息，为附件中的144.zip。
另外一台TiDB执行上面的SQL，现在执行了1600多秒还没有结束，但是CPU没有异常，debug信息我也抓下来了，为附件中的143.zip。
不好意思，这个不行，你还需要什么信息我可以提供。
@qihuajun 可以用 panic 关键字查下 144， 143 的 tidb 日志吗？看下是否有 slow_query 相关的 panic 的堆栈 ？
另外，之前 144 机器抓 debug 信息的时候，select * from slow_query limit 10; 语句是还在执行中吗？因为 debug 信息里面没有抓到 slow_query 相关的信息
另一台TiDB上也查询也执行完成了，执行了2600秒。下面是这个查询的一些信息：
执行计划：
id task estRows operator info actRows execution info memory disk
Limit_7 root 10 offset:0, count:10 10 time:9.255811515s, loops:2 N/A N/A
└─MemTableScan_10 root 10000 table:SLOW_QUERY 62 time:9.255798886s, loops:1 N/A N/A
上传的附件中的debug信息是在执行select * from slow_query limit 10;查询的时候抓的。
@qihuajun 从执行计划看，executor 执行的时间总共才 9.2 秒，但总的 SQL 执行耗时是 43 min, 是不是 select * from slow_query limit 10; 的返回结果数据量很大？
用 select count(*) from slow_query; 的执行时间是多久？
我把查询结果导出来之后确实还挺大的，有1.12G，我之前没想到这个表每一行的数据有那么大。
执行 select count(*) from slow_query; 这个查询在143上大概10秒左右，在144上4-9秒左右。
