【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
TiDB是如何判断大事务的？
主要是内存方面吧，对于大事务，需要提前做好内存规划，以确保系统的稳定性和性能。
具体有什么需求吗
我们在选型数据库，主要是AP和TP场景都有，会有INSERT INTO … SELECT…的场景，所以看了TIDB的大事务文档，没找到TIDB如何判断大事务的？还是说大事务是由开发进行判断，然后再规划、参数层面进行调整？
INSERT INTO … SELECT…主要你要评估内存占用，数据量太大会oom，需要调整内存参数，默认一条sql的tidb内存占用最大1G
确实是要规划好，要不总是OOM要烦死人
应该是执行之后才知道是大事务吧，不执行的话，只能根据数据量和执行计划预估吧。
1 个赞
大事务拆成小事务
TiDB 对单个事务的大小有限制，这层限制是在 KV 层面。
反映在 SQL 层面的话，简单来说一行数据会映射为一个 KV entry，每多一个索引，也会增加一个 KV entry。所以这个限制反映在 SQL 层面是：
- 最大单行记录容量为 120MB（TiDB v5.0 及更高的版本可通过 tidb-server 配置项
performance.txn-entry-size-limit调整，低于 TiDB v5.0 的版本支持的单行容量为 6MB）。 - 支持的最大单个事务容量为 10GB（TiDB v4.0 及更高版本可通过 tidb-server 配置项
performance.txn-total-size-limit调整，低于 TiDB v4.0 的版本支持的最大单个事务容量为 100MB）。
另外注意，无论是大小限制还是行数限制，还要考虑事务执行过程中，TiDB 做编码以及事务额外 Key 的开销。在使用的时候，为了使性能达到最优，建议每 100 ～ 500 行写入一个事务。
https://docs.pingcap.com/zh/tidb/v7.4/dev-guide-transaction-restraints#事务限制
1 个赞
insert into select 用非事务dml, tidb 会根据你的拆分分批执行！
https://docs.pingcap.com/zh/tidb/stable/non-transactional-dml#非事务-dml-语句
2 个赞
在 TiDB 中，如果一个事务访问的数据范围较大，持续的时间较长，则被认为是一个大事务。大事务可能会对系统性能和吞吐量造成很大的影响，因为它们需要锁定大量数据，可能会导致锁等待和死锁等问题。
因此，TiDB 提供了一种机制来判断大事务。在 TiDB 中，大事务是通过以下两种方式进行判断的：
- 记录事务操作的日志
当 TiDB 接收到一个事务时，会记录事务中的所有操作，并在 Log 内容中标记为一次事务。如果这个事务中执行的 SQL 语句数超过了系统设定的阈值，或持续时间超过了阈值，则被认为是一个大事务。TiDB 的默认阈值为 SQL 语句数大于 300 或者事务执行时间超过 5 秒。
- 检查锁等待时间
如果一个事务正在等待锁的时间超过了系统设定的阈值，则被认为是一个大事务。TiDB 的默认阈值为锁等待时间超过 50 秒。
当 TiDB 判断一个事务是大事务时，会将该事务标记为大事务，然后警告或者拒绝执行该事务。该机制可以通过修改 TiDB 的配置文件来调整，以适应不同的业务需求。
综上所述，TiDB 通过记录操作日志和检查锁等待时间等方式来判断大事务，以避免大事务对系统性能和吞吐量造成过大的影响。
支持的最大单个事务容量为 10GB
这里的事务容量是只的更新的数据的容量大小吗？
如果是的话，这个对大事务的支持是不是不太友好？单个事务10G，对大表而言要把一个更新分拆成很多个事务，但是目前TiDB应该是还不支持存储过程，这样的话，做一个大表的变更岂不是很麻烦？
调高内存限制参数，只要不OOM不用关心这个
我觉得应该是一个事务涉及的数据超过一定阈值时，被认为是大事务。比如tidb的单条sql查询的默认阈值tidb_mem_quota_query为1G，当你执行sql占用内存超过该值，可能就报错，给你认定为大事务。
但是有时候不管用，我设置了4G，但是一个sql跑出来十几G的内存，也没有报错
看你一直在推这个功能，用着咋样 
不应该吧，我们之前执行一个大sql就出错了，应该还是你的sql没有达到设置的最大值
tidb内存默认占用1g是小了，调到10g绝对可以应付各种场景了
都有什么要求呢
一个是运行时间，一个是运行占用内存量，建议对大事务分拆，避免出现OOM