直从使用tidb监控后，有些地方比较迷惑，尤其是定位CPU升高的SQL问题上。
16日 9点-10点 CPU异常升高，对比了3月13日9点-10点，存在相同的SQL，
无法定位到底是什么SQL引起的CPU升高问题。
TiDB 集群里 CPU 可能来自：
组件 CPU来源
TiDB SQL 解析、优化、执行
TiKV Coprocessor 计算
PD 调度
先看监控：
Grafana → TiDB Cluster
重点看：
TiDB CPU
TiKV CPU
判断：
TiDB CPU 高 → SQL 在 TiDB 层消耗
TiKV CPU 高 → SQL 在 TiKV 层计算
很多情况其实是：
TiKV Coprocessor CPU 高。
1 个赞
是Tikv CPU高，关键是如何定位是哪条或哪几条SQL引起的TIKV CPU高？
1 个赞
单台存储节点的Unified read pool CPu打满了。
第一个图的实例选到打满那台tikv，再看看有没有消耗特别高的SQL，以及大SQL是否变化。如果帖子里的已经是打满那台的话，那么感觉查查SQL执行的并发度是否有变化？
另外4.7小时的那条SQL，可以看下对应时刻执行计划是否有变化。
Unified read pool 这个要看并发设置的参数多大，服务器总的CPU核数是多少
选到cpu占用高的那个tikv节点看看有没有什么慢的SQL
show processes list 查询会话类型，同时检查相关节点检查对应的慢sql。
top sql?
你这集群io太高了，一般是有大量全表扫描或者不走索引的sql。
用 Top SQL 功能：Dashboard →「SQL 分析」→「Top SQL」，选择 16 日 9-10 点，按「CPU 使用率」排序，直接看占比最高的 SQL
没有按CPU使用率排序这个功能…
而且如果看Top SQL的话，图中3月16日和3月13日的TopSQL语句相同时间段9点-10点基本上是相同的。
而3月16日的Tikv CPU异常的高，而3月13日却没有这现象，所以单纯的从
TopSQL是看不出来是什么异常SQL导致Tikv CPU异常的高的。
直接在 3月16日异常时间段的慢日志中，找那条 SQL 的 TOTAL_KEYS 字段。如果这个数字异常巨大（例如几亿），那就是历史数据清理不及时 导致的；如果数字正常，那就是执行计划变了导致走了全表扫描。
你排查下慢sql，从io的使用率看，我觉的是大量的小表全表扫描的sql引起的
先根据dashboard提示的慢sql执行trace,看看各个部件的耗时情况
一般的情况是慢SQL执行时间长，并发一上来cpu就高了
可以看下sql语句分析里面，按照执行次数排序，看看哪些SQL执行次数最多，看监控图不像是某一两个大SQL引起的，像是一些代价不大，但是并发很高的引起的