大事务或长事务是否过多？是否引发锁等待、MVCC 版本堆积？

[yangyang (Ti D Ber A Lc My4qe)]

大事务或长事务是否过多？是否引发锁等待、MVCC 版本堆积？

[Kongdom]

没明白什么意思。

[北极星DB (Ti D Ber H0 A Jl5 Tn)]

问题过于高深

[初识TiDB (Ti D Ber 7stzly6a)]

很容易出问题

[初识TiDB (Ti D Ber 7stzly6a)]

避免大事务

[初识TiDB (Ti D Ber 7stzly6a)]

将其拆分为小事务

[waeng (Ti D Ber Nv9 Ord6n)]

查看TiKV的监控面板：

• TiKV-Details → Lock Manager ：查看等待锁的事务数、死锁数量等。
• TiKV-Details → Storage ：查看MVCC相关指标，如MVCC版本数量、旧版本数据大小

[随缘天空 (Ti D Ber Ivw R7o Pj)]

大事务尽量拆分下，有可能会出现锁等待或者乐观锁情况下的多次重试问题

[yg_2024 (yangguang)]

长事务会阻碍TiDB的GC。在TiDB的GC过程中，系统会计算"safe point"的时间戳。为了确保长时间运行的事务能够正常运行，safe point不会超过正在进行的事务的开始时间（start_ts）。这意味着：

• 长事务会"锁定"GC的safe point
• 阻止GC清理该事务开始时间之后的所有历史版本
• 导致大量过时数据无法被及时回收

不过业务上的大SQL一会先触发OOM，很少会导致阻碍gc。同时也有tidb_gc_max_wait_time参数可以控制长事务最大等待时间。

[异乡的大人 (Ti D Ber 2 Qs S2z Ws)]

大事务需要避免，尽量拆分，避免阻塞

[异乡的大人 (Ti D Ber 2 Qs S2z Ws)]

MVCC（Multi-Version Concurrency Control，多版本并发控制）是数据库系统中常用的一种技术，旨在提高数据库的并发性能和减少锁的使用，特别是在读写频繁的应用场景中。我专程找了一下度娘，哈哈

[麻辣机师 (Ti D Ber N Ec Hp7n S)]

和肯定会引发 ，建议短事务、单操作变批量操作、拆分大事务

[万仞听松 (Ti D Ber Ztf5y Jyk)]

能拆则拆

[北极星DB (Ti D Ber H0 A Jl5 Tn)]

但凡是数据库产品，都有MVCC的，解决读写冲突问题

[TiDBer_Ejh0eCXc]

a, too hard

[异乡的大人 (Ti D Ber 2 Qs S2z Ws)]

嗯，那哥们儿的帖子不删除了

[TiDBer_Ejh0eCXc]

@yangyang

大事务

很容易幻读,不可重复读. 不过得看隔离级别

[TiDBer_aaaaa (Ti D Ber J A Tfyx24)]

那肯定是容易出问题的！大事务或长事务一多，麻烦事儿就来了：首先是锁等待，比如你一个大事务占着某行数据的锁半天不放，其他事务想操作就得排队，搞不好还会触发死锁；然后是 MVCC 版本堆积，长事务会卡住 GC 的 safe point，旧版本数据清不掉，磁盘和内存都得跟着遭殃，时间久了集群性能都得往下掉。

所以最好的办法还是把大事务拆成小事务，尽量缩短事务的执行时间，别让它占着资源不撒手～

[TiDBer_YPbNvXxe]

避免大事务，将其拆分为小事务

[TiDBer_Ejh0eCXc]

可以按主键分批, 按分区处理, 这样可以拆小事务