一、現象

開發反應一張表的查詢時間很長，表的行數也不多，不應該有這種現象

二、排查

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相關：官網鏈接