storage read pool
storage read 主要是解决我们 查询中的 点查来单独设置的 线程池。及使用 主键与唯一索引进行等值查询，才会走 storage read pool 这个快速通道。通常情况下storage read pool 这里不应该看到很慢的场景
Storage read threads pool 可以通过以下监控来排查（下面的监控指标在 TiKV-Detail → Storage 下）：
- Storage command duration：执行 get 命令所需花费的时间（按照之前的说明，这部分时间就是调度之后，RocksDB->GetSnapshot() + Snapshot->Get(key) 的时间总和，所以不包含调度本身花费的时间）
- Storage command total：可以查看 get 命令的数量
- TiKV-Detail → Thread CPU ->Storage ReadPool CPU：Readpool 线程的 CPU 使用率
比较套路的排查思路是先看一下 CPU 是不是被打满了，如果被打满了看是不是命令的数量比较多，如果 CPU 没有打满，但是 Storage command duration 延迟比较高，就按照获取 Snapshot 和从 Snapshot 中获取 KV 比较慢进行排查（上面已讲，这里不再复述）