【 TiDB 使用环境】生产环境
【 TiDB 版本】V6.5.8
【遇到的问题：问题现象及影响】TIDB监控中TIKV-Details—>Thread CPU各项指标的建议值，从官方优化方案里看了一些，部分组件可通过配置进行优化，但是有些监控项经过修改配置后确实效果还是不明显，特别是如下UnifyReadPool监控指标，如果对于SQL读的行数较多场景，这个指标直接影响SQL耗时，这块大家遇到过么？
线上配置【服务器96C，部署了4个TIKV实例】：
readpool.storage.use-unified-pool = true
readpool.unified.max-thread-count = 30
readpool.unified.min-thread-count = 5
这一个核都没用到，不高啊。
现在还没有读请求，读请求到1万+的时候这个利用率就非常高了
还有个readpool.coprocessor.use-unified-pool: true设置了吗
默认先跑一下，再看
我检查了下，这个配置是关闭的，readpool.unified.auto-adjust-pool-size，这个参数靠谱么？
设置了是TRUE
你服务器96C，上面部署了4个tikv，做numa资源隔离了吗？，另外readpool.unified.max-thread-count = 30这个有点大了，建议设置为96/4*0.8=19左右就可以了。
另外readpool.unified.auto-adjust-pool-size这个参数，是在你cpu峰值能达到1500%（readpool.unified.max-thread-coun这是为19的情况下）左右，开启比较合理。
96/4*0.8=19，学习到了
如果设置了readpool.unified.auto-adjust-pool-size这个参数这个参数的话，在指定readpool.unified.max-thread-count = 30就没意义了吧
优化SQL，干嘛扫那么多数据，另外你96C机器，4个TiKV，你unified read pool用不到30吧，不够分啊
https://docs.pingcap.com/zh/tidb/v6.5/tikv-configuration-file#auto-adjust-pool-size-从-v630-版本开始引入
max-thread-count也是这个参数的调整阈值啊
SQL层面优化过了，部分SQL走索引后行检索还是很多
我在调整下压测看看
压力不大呀
我都没改过
是因为有不少Indexfullscan?
