tidb-gc长时间不变动引起的慢查询

原创已于 2022-07-12 09:50:52 修改 · 524 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#数据库

于 2022-07-11 18:16:17 首次发布

TIDB 专栏收录该内容

63 篇文章

订阅专栏

本文介绍了在TiDB中遇到的一张小表查询速度慢的问题，通过查看表信息、执行计划和GC设置，发现由于长时间未执行GC导致版本过多。调整`tikv_gc_life_time`参数至合理值后，查询性能恢复正常。排查过程涉及索引、表健康度和TiKV的GC机制。

一、现象

开发反应一张表的查询时间很长，表的行数也不多，不应该有这种现象

二、排查

1.查看表的基本信息

# 查看表结构
show create table table_name;
# 查看表行数
select count(1) from table_name;
# 查看表健康度
show stats_healthy where table_name = "table_name"
# 查看查询的执行计划
explain analyze sql

通过上面的查询知道表的行数只有两千多行，没有索引，正常来说是应该为毫秒级的查询，但是执行计划中可以看到rpc_num 1, rpc_time：52s
rpc_num: 向 TiKV 发送 Cop 类型的 RPC 请求总数量
rpc_time: 向 TiKV 发送 Cop 类型的 RPC 请求时间

2.探索cop慢原因

2.1 加索引分析

同样的查询加上索引就快了，但是根据经验判断，2000多行的表有无索引的情况是一致的，除非优化器认为他真实的数据远大于2000行，所以猜测是我们的版本数太多试造成cop慢的主要原因

2.2 查看gc设置

# 通过这个查看gc,发现tikv_gc_last_run_time是6月28号，而现在已经是7月11号了，没有gc是造成版本太多的主要原因
select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like "tikv_gc%";

# 另外可以看到tikv_gc_life_time为10m0

2.3 解决gc问题

通过上面的查询也可以看到tikv_gc_life_time为10m0，这个是个不合理的gc值，所以会造成不能gc,合理的值为10m或者10m0s，这块在v5版本中用set的方式就可以避免了，4版本中还是需要用下面的方式进行

# tidb中的错误日志
 ["[gc worker] leader tick"] [error="time: missing unit in duration 10m0"]

# 如下修改后gc后，查询变得正常
update mysql.tidb set VARIABLE_VALUE="10m0s" where VARIABLE_NAME="tikv_gc_life_time";

gc相关：官网链接