读性能慢-热点问题

判断读热点依据

方式一:在监控面板 TiKV-Details -> Thread CPU 中查看

若开启了 Unified read pool,查看是否有某个 TiKV 的 Unified read pool CPU 明显高于其他 TiKV 节点

若未开启 Unified read pool,查看是否有某个 TiKV 的 Coprocessor CPU 明显高于其他 TiKV 节点

方式二:在监控面板 TiKV-Throuble-Shooting -> Hot Read 中查看

查看是否存在某个 TiKV 的指标明显高于其他 TiKV 节点

若确定存在读热点,需定位到具体的热点表或索引

方式一:通过 tidb dashboard 热力图定位(推荐方式)

对于读热点,在热力图中一般表现为一条明亮的横线,通常是有大量访问的小表

将鼠标移动到亮色块上可以看到具体什么表或索引上有大流量

方式二:通过 TiDB API

查询读流量最大的 Region ID

pd-ctl -u http://{pd}:2379 -d region topread [limit]

根据 Region ID 定位到表或者索引

curl http://{TiDBIP}:10080/regions/{RegionId}

1赞

读热点解决方法

根据监控面板 TiKV-Details -> RocksDB KV -> Block Cache hit 命中率来判断

  • 若 BlockCache 的命中率下降或者抖动,可能是存在全表扫描的 SQL、执行计划选择不正确的 SQL、存在大量 count(*) 操作的 SQL 等等,解决方法:
  1. 优化具体的 SQL
    若 BlockCache 命中率比较稳定,则可能是 Region 并发读取过高导致,在业务查询频繁的命中个别 Region 最终时会导致单个 TiKV 节点性能达到极限,几种解决方法供参考:
  2. 在 4.0 版本中 针对小表的读热点提供了新的解决办法 Load Base Split ,通过调整 TiKV 参数 set config tikv split.qps-threshold=2000 到一个更小的值来 解决读热点问题。具体操作方法参见链接 。
    • Load Base Split
    • 传统的方法: 将小表改造成 hash 分区表,打散 Region 分布,或者将小表热点 region leader 进行手工 split 和 transfer
  3. 若同时也存在写热点,可以使用 shard_row_id_bits 处理热点表,可以有效缓解读写热点问题
  4. 开启 Coprocessor Cache 功能,开启该功能后,将在 TiDB 实例侧缓存下推给 TiKV 计算的结果,对于小表读热点能起到比较好的效果
  5. 使用 Follower Read 功能,在一定程度上可以缓解读热点问题 此特性目前还是实验特性

bloom prefix是什么指标,没有搜到

https://zh.wikipedia.org/wiki/布隆过滤器 参考下吧

收到,谢谢