连的同一个tidb server ， 每次执行同一个查询语句，响应时间相差比较大，各位大神帮忙看看什么地方遇到了瓶颈
------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------
辛苦按照 提问须知，提供 tidb 版本，表数据量等相关信息。
总共才一行数据，这上面执行的慢的时候花了 1 秒多钟，集群这段时间是不是比较忙？看看 tidb slow log 中这条 sql 执行时间 1 秒多钟的 log 呢？另外提供一下 select tidb_version() 的结果，看看具体是什么版本的 TiDB
select tidb_version() 的结果
Release Version: v3.0.2
Git Commit Hash: 94498e7d06a244196bb41c3a05dd4c1f6903099a
Git Branch: HEAD
UTC Build Time: 2019-08-07 02:35:52
GoVersion: go version go1.12 linux/amd64
Race Enabled: false
TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e
Check Table Before Drop: false
看看 tidb slow log 中这条 sql 执行时间 1 秒多钟的 log 呢？
slow log 日志调整为3秒以上记录了，这个1秒多的没记录
可以调整下 slow log 的阈值，能抓到这类语句的具体执行信息（比如 1s），方便分析问题。
这个和最近MT的问题是不是一个原因啊？
你的 duration 耗时太高了，可以先看看 TiKV metrics 面板里面的 gRPC duration，如果耗时也很高，那就是 TiKV 有瓶颈，如果不高，那就是 TiDB 太忙了。
旧版本过多，往往是 gc 不及时。关于 gc 的配置可以查看：https://pingcap.com/docs-cn/v3.0/reference/garbage-collection/configuration/。其中比较重要的几个参数： tikv_gc_run_interval， tikv_gc_life_time和 tikv_gc_concurrency
旧版本过多，往往是 gc 不及时。关于 gc 的配置可以查看：https://pingcap.com/docs-cn/v3.0/reference/garbage-collection/configuration/。其中比较重要的几个参数：
tikv_gc_run_interval，tikv_gc_life_time和tikv_gc_concurrency
gc的时间与内存消耗有关系吗
GC 主要是针对因为 Drop，Truncate table，或者 DML 产生的版本进行清理，原则上不会与内存消耗有直接的关联。版本过多，会影响 sql 的查询效率，并且对 tikv 的内存会产生一定的影响。
如果是因为 GC 不及时，导致慢查询，processed key 和 total key 的数量差异比较大，则建议查看 GC 相关的配置以及 GC 运行的状态。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
