TIDB SQL出现抖动，rpc_time耗时徒增

[TiDBer_SpYBwH2O]

【TiDB 使用环境】生产环境
【TiDB 版本】4.0.13
【部署方式】机器部署
TIDB V4数据库这个SQL

Time: 2026-09-09T10:57:28.029732938+08:00

Txn_start_ts: 468955338532716757

User@Host: spam_user[spam_user] @ 10.43.129.189 [10.43.129.189]

Conn_ID: 4417689

Query_time: 0.389233557

Parse_time: 0.000074648

Compile_time: 0.000487895

Rewrite_time: 0.000101837

Optimize_time: 0.000231089

Wait_TS: 0.000008662

Cop_time: 0.388222849 Wait_time: 0.387 Request_count: 2 Total_keys: 3 Process_keys: 2

DB: tdb_spam_oltp

Index_names: [certification_sequence:uid_status_idx]

Is_internal: false

Digest: 69fdde7d69627e295995fca3ba984bb1af14bde9e0e80462e11fd00225b4f864

Stats: certification_sequence:468952193696006300

Num_cop_tasks: 2

Cop_proc_avg: 0 Cop_proc_p90: 0 Cop_proc_max: 0 Cop_proc_addr: 10.40.65.179:17114

Cop_wait_avg: 0.1935 Cop_wait_p90: 0.387 Cop_wait_max: 0.387 Cop_wait_addr: 10.40.65.179:17114

Mem_max: 38340

Prepared: false

Plan_from_cache: false

Plan_from_binding: false

Has_more_results: false

KV_total: 0.388144419

PD_total: 0.000007432

Backoff_total: 0

Write_sql_response_total: 0.000002535

Succ: true

Plan_digest: 23ad452d0f5e963489e55c2bfcd9d7f05269d5a9ac61f7927616fb194c0a9fd2

SELECT id,uid,auth_source,real_name,idcard,auth_status,reason_tx,reason_us,info_id,to_uid,order_id,time,datas,face_id,code,ip,idcard_encode,pic_secret_key,extra_data,pic_media,c
onstellation,real_name_encode FROM certification_sequence WHERE (uid = xxxxxxx AND auth_status IN (1)) ORDER BY time DESC;

	id	task	estRows	operator info	actRows	execution info	memory	disk
	Projection_4	root	2.07	tdb_spam_oltp.certification_sequence.id, tdb_spam_oltp.certification_sequence.uid, tdb_spam_oltp.certification_sequence.auth_source, tdb_spam_oltp.certification_sequence.real_name, tdb_spam_oltp.certification_sequence.idcard, tdb_spam_oltp.certification_sequence.auth_status, tdb_spam_oltp.certification_sequence.reason_tx, tdb_spam_oltp.certification_sequence.reason_us, tdb_spam_oltp.certification_sequence.info_id, tdb_spam_oltp.certification_sequence.to_uid, tdb_spam_oltp.certification_sequence.order_id, tdb_spam_oltp.certification_sequence.time, tdb_spam_oltp.certification_sequence.datas, tdb_spam_oltp.certification_sequence.face_id, tdb_spam_oltp.certification_sequence.code, tdb_spam_oltp.certification_sequence.ip, tdb_spam_oltp.certification_sequence.idcard_encode, tdb_spam_oltp.certification_sequence.pic_secret_key, tdb_spam_oltp.certification_sequence.extra_data, tdb_spam_oltp.certification_sequence.pic_media, tdb_spam_oltp.certification_sequence.constellation, tdb_spam_oltp.certification_sequence.real_name_encode	0	time:483.5ms, loops:1, Concurrency:OFF	9.81 KB	N/A
	└─IndexLookUp_13	root	2.07		0	time:483.5ms, loops:1, table_task: {total_time: 1.93s, num: 0, concurrency: 4}	220 Bytes	N/A
	├─IndexRangeScan_11	cop[tikv]	2.07	table:certification_sequence, index:uid_status_idx(uid, auth_status), range:[1906684415983783937 1,1906684415983783937 1], keep order:false	0	time:483.4ms, loops:1, cop_task: {num: 1, max: 483.3ms, proc_keys: 0, rpc_num: 1, rpc_time: 483.3ms, copr_cache: disabled}, tikv_task:{time:0s, loops:1}, scan_detail: {total_process_keys: 0, total_keys: 1}	N/A	N/A
	└─TableRowIDScan_12	cop[tikv]	2.07	table:certification_sequence, keep order:false	0		N/A	N/A
SQL执行计划很优，正常情况RPC_time在几毫秒左右，现在出现问题在几百毫秒。整个sql都慢在这里Cop_wait_p90: 0.387
是什么原因导致的？该如何优化，请各位大佬帮帮忙

[xfworld (魔幻之翼)]

升级… 版本太旧了

[kang]

看这个慢日志，问题比较明显：Cop_time 占了绝大部分，其中 Wait_time: 0.387 说明主要耗时在等待 coprocessor 响应，而不是实际计算（Cop_proc_avg: 0）。

建议从这几方面排查：

1. 检查 TiKV 节点负载：登录 10.40.65.179 看下 CPU、磁盘 IO、网络是否打满，用 top 和 iostat 确认。

[wbslxw (Ti D Ber Cl S0j Eng)]

Cop_proc≈0 而 Cop_wait=388ms，是 “等” 不是 “算”；去 10:57 那个时间点对监控（TiKV 排队 + 网络），大概率是那台 TiKV 节点瞬时忙或链路抖动

[像风一样的男子]

4.0版本别挣扎了 直接升级到最新版本，百分之99的问题都能解决

[Circle (Hacker Nc Kk Uyct)]

@TiDBer_SpYBwH2O

Cop_wait_addr: 10.40.65.179:17114

看下 wait 的这台 tikv 是不是有热点或者性能瓶颈

[lmdb (: " One day my life will end, and you will wear the crown.")]

是持续的问题嘛，还是偶发的

[会飞的小老鼠 (Ti D Ber Q0 Hx Lgd S)]

简单结论：你的 SQL 和索引计划都没问题，慢在 Cop_wait（等 TiKV 处理），不是 SQL 本身的锅。

看数据说话

• Cop_proc: 0 —— 真正执行几乎不耗时间；
• Cop_wait: 0.387s、Cop_wait_p90: 0.387 —— 0.39 秒几乎全花在排队等 TiKV 的读线程池；
• 计划扫 2 行、2 个 cop task，正常应该几毫秒。

也就是说：请求发到 TiKV（10.40.65.179）后在读线程池里排队，说明那台 TiKV 忙不过来，被别的查询占满了。

常见原因

1. 有大查询 / 全表扫描把 coprocessor 线程池占满，小查询跟着排队（最常见）；
2. 该 TiKV 节点有热点 Region 或负载不均；
3. 后台任务抢资源：analyze、备份、compaction 高峰期；
4. 4.0 的 read pool 线程数配置偏小。

怎么查 + 怎么优化

1. 打开 TiKV Details 面板，看 Readpool/Unified read pool 的 CPU 使用率和排队（level 0 队列），确认是否打满；
2. 去慢查询列表筛 Cop_wait 高的大 SQL，找到占线程池的元凶（大概率是某条全表扫或超大 scan），优化它比调参更有效；
3. 若确认是线程池打满且机器有富余 CPU，再调大 readpool.unified.max-thread-count（4.0 是 unified，改完滚动重启）；
4. 看有没有热点：检查 Region 大小 / 流量分布，必要时用 tiup ctl pd 做热点调度或手动 split；
5. 4.0.13 已很老（早已 EOL），长期建议升级到 6.5/7.x/8.x，读路径和调度都强很多。

[TiDBer_odwPM8gO]

这么老的版本还在用