长时间大事务、慢查询会造成 MVCC 版本过多，磁盘占用上涨、查询变慢。除了等待 GC，还有哪些应急和根治方案？
根源还是解决大事务吧。
调低gc的触发时间也解决不了问题。
在生产环境中，我们通常会将 tidb_gc_life_time 适当调大（4h~24h，默认是10分钟），以便在数据误操作时可以进行闪回。由于默认事务内存限制为1G，长事务或慢 SQL 的持续时间通常短于 4 小时，因此由 SQL 触发大量 MVCC 版本堆积的情况相对少见，此类消耗多源于主动调整 GC 生命周期所致。若确实因大事务导致 MVCC 版本过多，可以采取以下措施：
- 应急措施：
KILL相关会话。 - 根治措施：合理设置
tidb_mem_quota_query，以限制单个事务的内存使用上限。
TiDB 的兼容性跟执行计划的生成机制有关，同样的 SQL 在 MySQL 和 TiDB 上的优化器决策可能不同，特别是子查询和 JOIN 的处理方式。迁移前建议用 SQL Plan Management 做下 SQL 兼容性扫描。
还是从业务层面解决这类问题吧,gc是回收处理的唯一系统途径
TiDB 的兼容性跟执行计划的生成机制有关，同样的 SQL 在 MySQL 和 TiDB 上的优化器决策可能不同，特别是子查询和 JOIN 的处理方式。迁移前建议用 SQL Plan Management 做下 SQL 兼容性扫描。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。