某个store响应时间比其他节点要慢很多，原因是在进行Cop操作，如何快速定位是那个SQL语句导致的呢？

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】生产环境
【TiDB 版本】7.5.3
【操作系统】
【部署方式】云上部署（腾讯云）
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

如下图所示，某个store节点的响应比其他节点要慢的很多，从操作类型上看是进行Cop操作，有什么方法能快速定位到是那个SQL执行导致的吗？

image
image2828×514 138 KB

ps ，慢查里面没有特别慢的，基本都在1秒左右

2

慢查询里是执行完成的，可能是正在执行完成的，查这个表cluster_processlist

3

这个表能看到当前执行的sql 但是没有办法关联到Cop对应的store呢，

4

cop本来就是个耗时，核心的功能，高点可能是正常的

5

高了会影响到store的响应，如果某个store的响应太慢的话，会影响到整体查询响应情况的。之前出现过类似的问题，所以比较关注这个

6

没有太高的，是不是并发的数量导致的？有热点导致的单台高?

7

嗯对，最终根据监控看到这个store qps确实比其他高出来很多，然后结合 information_schema.slow_query 慢查出现的多少，定位是开发这边在跑个任务导致，时间基本吻合的

8

个人理解，排除region分布不均的场景
是查询造成的需要查询的region的leader region,分布在某一台kv上较多，经常或并发使用该查询，就可能造成这台kv的压力较高

9

看 top sql

10

先统计分析下这两张表的top，排查是不是sql热点：
information_schema.cluster_slow_query
nformation_schema.cluster_statements_summary

11

在 TiDB 中，Cop 操作（Coprocessor 任务）是 TiKV 节点处理的分布式计算任务（如索引扫描、表扫描、聚合、过滤等），由 TiDB Server 下发到 TiKV 执行。当某个 store 节点的 Cop 操作响应变慢时，可通过以下步骤快速定位到对应的 SQL：

核心思路

Cop 操作的慢响应通常与访问该 store 节点的 SQL 语句直接相关（例如，SQL 需要扫描该 store 上的大量数据，或该 store 上的数据存在热点）。定位的关键是将慢 Cop 任务与具体 SQL 关联，可通过 TiDB 内置工具（Dashboard、Statement Summary）和日志分析实现。

具体步骤

1. 利用 TiDB Dashboard 定位慢 Cop 对应的 SQL（最直接）

TiDB Dashboard 聚合了集群的 SQL 执行、Cop 任务等信息，可直接关联慢 Cop 任务与 SQL。

操作步骤：
  1. 访问 TiDB Dashboard（默认地址：http://{pd-ip}:2379/dashboard），进入 “SQL 语句分析” 页面。
  2. 切换到 “慢查询” 标签页，筛选时间范围（选择 store 节点变慢的时间段）。
  3. 关注 “执行耗时” 较长的 SQL，尤其注意带有 TableScan、IndexScan、HashAgg 等算子的 SQL（这些算子会触发大量 Cop 任务）。
  4. 点击具体 SQL 进入详情页，查看 “执行详情” 中的 “Coprocessor 任务统计”：
  • 会显示该 SQL 下发到哪些 TiKV store 的 Cop 任务，以及每个任务的耗时。
  • 若某个 store 的 Cop 任务耗时远高于其他节点，即可确认该 SQL 是导致目标 store 变慢的候选者。

2. 通过 Statement Summary 表筛选高频 / 高耗时 SQL

TiDB 的 information_schema.statements_summary 表记录了 SQL 的执行统计信息（包括 Cop 操作相关指标），可通过该表筛选访问目标 store 的 SQL。

操作步骤：
  1. 执行以下 SQL 查询，筛选出 Cop 操作耗时高的 SQL：

sql

SELECT 
  query_id, 
  digest_text,  -- SQL 语句（参数化后）
  sum_cop_time,  -- Cop 操作总耗时
  sum_exec_count,  -- 执行次数
  avg_cop_time   -- 平均 Cop 耗时
FROM 
  information_schema.statements_summary
WHERE 
  sum_cop_time > 0  -- 只看有 Cop 操作的 SQL
ORDER BY 
  sum_cop_time DESC  -- 按 Cop 总耗时排序
LIMIT 10;
  1. 对筛选出的 SQL，结合 ADMIN SHOW SQL DIGESTS 查看完整语句：

sql

ADMIN SHOW SQL DIGESTS WHERE digest = 'xxx';  -- digest 从上面的 digest_text 对应获取
  1. 进一步分析这些 SQL 的执行计划（用 EXPLAIN ANALYZE），确认是否需要扫描目标 store 上的 Region（可通过 EXPLAIN ANALYZE 中的 task 字段看到 Cop 任务的分布）。

3. 分析 TiDB 日志，关联 Cop 任务与 SQL

TiDB Server 的日志会记录每个 SQL 下发的 Cop 任务详情（包括目标 store ID、耗时等），可通过日志直接定位。

操作步骤：
  1. 找到 TiDB Server 的日志文件（默认路径：${tidb-data-dir}/tidb.log）。
  2. 筛选目标 store 节点（假设 store ID 为 123）的 Cop 任务日志，关键字为 cop + store_id=123：

bash

grep -E "cop.*store_id=123" tidb.log | grep -i "slow"  # 筛选慢 Cop 任务
  1. 日志中会包含 sql_id 字段（如 sql_id=abc123），通过 sql_id 查找对应的完整 SQL：

bash

grep "sql_id=abc123" tidb.log  # 找到该 SQL 的完整文本

或通过 Dashboard 的 “SQL 语句分析” 页面，搜索 sql_id 定位 SQL。

4. 结合 TiKV 监控，确认 Cop 慢的原因

定位到可疑 SQL 后，需确认该 SQL 是否确实在目标 store 上产生了大量耗时的 Cop 操作，可通过 Grafana 监控验证：

  1. 打开 TiKV 的 Grafana 面板（默认路径：http://{grafana-ip}:3000），进入 “TiKV - Coprocessor” 面板。
  2. 筛选目标 store 节点（通过 store_id 过滤），查看以下指标：
  • Coprocessor request duration：Cop 任务处理耗时（P95/P99 latency）。
  • Coprocessor requests total：Cop 任务数量（是否有突增）。
  • Coprocessor scan keys：扫描的键数量（若过大，说明 SQL 扫描了大量数据）。
  1. 若这些指标在对应 SQL 执行时段明显升高，即可确认该 SQL 是导致 store 变慢的原因。

常见场景与优化建议

  1. SQL 扫描大量数据：例如全表扫描、无索引的大范围查询，会导致目标 store 上的 Cop 任务需要扫描大量数据。
  • 优化：为查询字段添加索引，或限制扫描范围（如加 LIMIT、优化过滤条件）。
  1. 数据热点：目标 store 上的某个 Region 被频繁访问（如高频更新 / 查询某段数据），导致 Cop 任务排队。
  • 优化：通过 ADMIN SHOW HOT REGIONS 查看热点 Region，结合业务拆分热点数据（如分表）。
  1. TiKV 节点资源瓶颈：目标 store 所在的 TiKV 节点可能存在 CPU 使用率过高、I/O 繁忙（如磁盘读写慢），导致 Cop 任务处理延迟。
  • 验证：通过 top、iostat 查看节点资源，若资源瓶颈明显，可扩容节点或迁移数据。

通过以上步骤，可快速将慢 Cop 操作与具体 SQL 关联，进而针对性优化。核心是利用 TiDB Dashboard 和日志建立 “Cop 任务 - SQL - 目标 store” 的关联关系

12

多谢多谢，回答中对我而言有多学了几个知识点。

13

太强了