SQL 查询超过2分钟，执行计划显示limit慢

[大飞飞呀]

你没用limit时候大多数的region结果缓存在tidb这边了，只需要去tikv发送个rpc看region是否发生了变化，如果没有变化，那么你查询涉及到的这个region数据就是准确的，代价仅仅是一个rpc请求。如果某个region数据发生了变化(更新了版本)。那么就需要重新查询这个region的数据。从这个查询缓存率可以看出你只需要重新扫描大约10%的region即可。所以你看到的一个是10亿，一个是1亿，大约相差10倍。

[大飞飞呀]

总结一下，造成上面问题的共有三处可以优化

1. 修改参数tidb_gc_life_time，目前是8小时，可以修改为10分钟
2. 官方bug：https://github.com/tikv/tikv/issues/11217
   影响版本

• v5.0.0-v5.0.4
• v5.1.0-v5.1.2
• v5.2.0-v5.2.2

issue: https://github.com/tikv/tikv/issues/11217
TiKV GcKeys task doesn’t work when called with multiple keys (at least in 5.1 but I think for everything)

现象和确认方法

• 部分 scan 相关操作执行慢，集群中有比较多的 UPDATE/DELETE 语句执行
• EXPLAIN ANALYZE 的 scan detail 中显示 key_skipped_count 远远多于 total_process_keys 或者 slow log 中 key_skipped_count 远远多于 total_process_keys

解决方案

• 设置 gc.enable-compaction-filter: false 以关闭 TiKV 的 compaction filter GC，使用旧的 GC 模式进行多版本 GC
• 升级到新版本，如上所述选择发行版最新的发布版本

3. 去除limit ，走缓存
   没用limit时候大多数的region结果缓存在tidb这边了，只需要去tikv发送个rpc看region是否发生了变化，如果没有变化，那么你查询涉及到的这个region数据就是准确的，代价仅仅是一个rpc请求。如果某个region数据发生了变化(更新了版本)。那么就需要重新查询这个region的数据。

[南征北战 (Ti D Ber Cq L Kg8y L)]

加了limit，优化器会按key进行排序。