【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
v4.0.8
【复现路径】做过哪些操作出现的问题
修改mysql.tidb表，tikv_gc_life_time原来是24h，改成10m，大约过了1小时左右，大量空region产生，tidb内的时延增长。
update mysql.tidb set VARIABLE_VALUE=‘10m’ where variable_name=‘tikv_gc_life_time’;
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
gc 做的太快了呗，消耗太多资源，反而导致性能下降，所以你别一下从 24h 改为 10min 啊，可以慢慢改
正常，GC要把之前的过期数据清理掉，可以晚上调小，或者一点一点的调小。
gc时间一下子从24小时设置为10m，导致大量旧数据都要被标记为删除，在删除大量数据后，如果没有及时通过 Region Merge 来减少 Region 的数量，可能会导致大量空 Region 的产生。所以应该逐步缩小这个设置，而不能一次性缩短那么多
将 tikv_gc_life_time 从24h减少到10m时，短时间内需要清理大量的mvcc数据版本；
GC进程清理大量的数据版本，会产生很多空 Region；
大量的GC任务会导致TiDB的性能下降，因为系统需要处理更多的GC任务。
是这个道理，楼主的操作有点激进，在业务高峰还是业务低谷期都风险挺大的，而且楼主的版本太低了。
后面还有修改回更大一点的值吗？
tikv资源是不是较低，高的，就gc任务的进程，应该不会太大影响。
gc 24小时。就是他保留了24小时内的所有的删除更新操作，10分钟执行一次，删除24小时前的也是删除10分钟的数据量，你突然改成10分钟.那他就怎么做呢？
他要全力甚至爆缸去删除23小时50分钟的所有的数据。那肯定要占用大部分的 资源来操作。
如果影响已经结束了。那就不用管了。后面他影响也不大，如果还在影响着，那就调高一点。看看他tikv_gc_safe_point这个时间是多少。调整和这个时间差不多。就不会继续gc了。然后在慢慢减少 到10分钟。
尽量别改
正常现象，延长gc时间，会消耗集群资源，性能下降