tidb 相同sql 连续执行多次返回时间不一样

【问题】 当前遇到的问题

表4GB
数据量1000w左右

表字段定义如下：

对表连续进行相同的update，返回结果最慢能到1s多，最快几ms

表索引情况：

【背景】 做过哪些操作
创建apk_md5_check_time复合索引，业务尝试还是一样，返回结果时间不稳定

【TiDB 版本】
5.7.25-TiDB-v4.0.8

• 麻烦提供一下这个 SQL 相关的表的 show create table 的信息。
• 执行时间较长的以及快的 explain analyze 的 update 的信息 (注意：explain analyze 会执行该 SQL )
• 导出一下这个 sql 相关表的统计信息：https://docs.pingcap.com/zh/tidb/stable/statistics#导出统计信息
• 提供一下这个 update 的 SQL 文本 (非截图)

（1）CREATE TABLE apk_snap_history (
apk_md5 varchar(32) NOT NULL DEFAULT ‘’,
check_time datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
apk_sha1 varchar(40) NOT NULL DEFAULT ‘’,
apk_name varchar(100) NOT NULL DEFAULT ‘’,
apk_name_pinyin varchar(100) NOT NULL DEFAULT ‘’,
apk_icon_md5 varchar(32) NOT NULL DEFAULT ‘’,
apk_icon_ocr varchar(100) NOT NULL DEFAULT ‘’,
apk_package varchar(100) NOT NULL DEFAULT ‘’,
apk_rsa_finger_sha256 varchar(64) NOT NULL DEFAULT ‘’,
apk_version_name varchar(64) NOT NULL DEFAULT ‘’,
success varchar(1) NOT NULL DEFAULT ‘0’,
apk_remark varchar(100) NOT NULL DEFAULT ‘’,
apk_state varchar(100) NOT NULL DEFAULT ‘105’,
apk_type varchar(100) NOT NULL DEFAULT ‘’,
add_time datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
add_user varchar(50) NOT NULL DEFAULT ‘’,
update_user varchar(50) NOT NULL DEFAULT ‘’,
update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
apk_rsa_finger_md5 varchar(32) NOT NULL DEFAULT ‘’,
save_state varchar(10) NOT NULL DEFAULT ‘0’,
pushed varchar(10) NOT NULL DEFAULT ‘0’,
apk_mfsha1 varchar(40) NOT NULL DEFAULT ‘’,
KEY idx_apk_md5 (apk_md5),
KEY idx_apk_name (apk_name),
KEY idx_apk_package (apk_package),
KEY idx_add_time (add_time),
KEY idx_check_time (check_time),
KEY idx_apk_rsa_finger_md5 (apk_rsa_finger_md5),
KEY idx_apk_mfsha1 (apk_mfsha1),
KEY idx_apk_md5_check_time (apk_md5,check_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

（2）奇怪执行explain analyze 没返回执行计划

（3）表统计信息
统计信息.log (4.3 MB)
（4）update 语句如下
update apk_snap_history set save_state=‘2’, update_time=update_time where apk_md5=‘fa6fc358382711063d3c088293969199’ and check_time=‘2021-03-19 11:13:21’;

辛苦也给一下 trace format='row' 的结果。执行较快以及执行比较慢的都给一下。
https://docs.pingcap.com/zh/tidb/stable/sql-statement-trace#trace

辛苦大佬了

执行下 explain analyze select save_state, update_time from apk_snap_history where apk_md5=‘fa6fc358382711063d3c088293969199’ and check_time=‘2021-03-19 11:13:21’;
看下结果
并且 在 tidb 的 slow_query log 中找下对应 的慢语句记录 确认是否因为冲突写导致了 backoff

偶尔会有select 这个表的操作，下面是两个快慢的执行计划
慢的执行计划
tidb_decode_plan('7ATgMAkyOF80CTAJMAlOL0EJMAl0aW1lOjEuMjA2MTk3NDcycywgbG9vcHM6MSwgCTEwLjY1NjI1IEtCAS94CjEJMzBfMTEJMAkyLjAyNDYyNDEyMDQxMjc0MQkJMR1MFDA5ODI4NRVMwDIsIGNvcF90YXNrOiB7bnVtOiAxLCBtYXg6MTIyLjI2MDc2OW1zLCBwcm9jX2tleXMFIAxycGNfESwBDAWrACAFMgw0ODcwBT: id task estRows operator info actRows execution info memory disk
Update_4 root 0 N/A 0 time:1.206197472s, loops:1, 10.65625 KB N/A
└─IndexLookUp_11 root 2.024624120412741 1 time:1.206098285s, loops:2, cop_task: {num: 1, max:122.260769ms, proc_keys: 1, rpc_num: 1, rpc_time: 122.248709ms, copr_cache_hit_ratio: 0.00} 18.671875 KB N/A
├─IndexScan_9 cop[tikv] 2.024624120412741 table:apk_snap_history, index:idx_apk_md5_check_time(apk_md5, check_time), range:[“fa6fc358382711063d3c088293969199” 2021-03-19 11:13:21,“fa6fc358382711063d3c088293969199” 2021-03-19 11:13:21], keep order:false 1 time:1ms, loops:1 N/A N/A
└─TableScan_10 cop[tikv] 2.024624120412741 table:apk_snap_history, keep order:false 0 time:0ns, loops:0 N/A N/A
1 row in set (0.00 sec)

快的执行计划：

id task estRows operator info actRows execution info memory disk
Update_4 root 0 N/A 0 time:175.652047ms, loops:1, 10.65625 KB N/A
└─IndexLookUp_11 root 2.024624120412741 1 time:175.56092ms, loops:2, cop_task: {num: 1, max:603.091µs, proc_keys: 1, rpc_num: 1, rpc_time: 585.521µs, copr_cache_hit_ratio: 0.00} 18.671875 KB N/A
├─IndexScan_9 cop[tikv] 2.024624120412741 table:apk_snap_history, index:idx_apk_md5_check_time(apk_md5, check_time), range:[“fa6fc358382711063d3c088293969199” 2021-03-19 11:13:21,“fa6fc358382711063d3c088293969199” 2021-03-19 11:13:21], keep order:false 1 time:0s, loops:1 N/A N/A
└─TableScan_10 cop[tikv] 2.024624120412741 table:apk_snap_history, keep order:false

走的索引都一样，就是cop_time 不一致

看执行计划 rpc time 有异常

1. 确认下网络情况 个服务器之间的 网络 ping 值是否在 2ms 以内 ；如果是则网络问题
2. 确认是否有 tikv 存在热点问题 ；如果是 则大概率是热点问题
3. 确认整个集群 每个 tikv 管理的 region 数量超过 3w；如果是可能是 tikv 管理 region 数量过多导致 mutrx 锁竞争不能有效获得数据产生了等待
4. 确认 tikv 节点 顺序写随机读 满足 1w iops 和 1G 磁盘带宽；如果是那么 IO 不达标时候 会更容易在 GC 与 rocksdb compaction 时候产生问题 3

这是个180TB的超大集群，每个tikv region 在20多w，感谢您的回答，我怀疑大概率是这个问题，其它的我逐一排查下

发现某个tikv 系统cpu 负载相对其它kv节点非常高，下面是grafa一些监控指标

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。