以前在使用oracle的时候，单个事务的更新行数可以达到两百万，现在我们这边做国产化换tidb，要求单个事务更新行数不超过1000，导致很多insert into select…,delete,update的单条sql因为更新行数超过1000了，要改成先一千条每页的去分页查出每页主键区间，然后根据主键区间一页一页的去操作，这种改法一是繁琐而是效率影响大，问了项目处为什么事务限制的这么小，说是因为是分布式数据库要考虑节点同步问题，所以我在这里问下项目处对事务的限制合理吗？
一般建议事务在2000左右，包括Oracle也一样，只是大一点的事务也支持，但不是最佳选择
夜间批处理事务大小也是两千内比较好吗
你指的是要硬性限制所有事务都要两千以下，还是只要大部分事务都在两千以下，偶尔有几个事务比较大也无妨
也不是硬限制，可以改啊，主要是需要评估下业务的影响吧，默认的是一个相对安全的配置
1 个赞
默认事务1G，最大事务10G。我们这边是部署的时候就直接设置为10G了。
1 个赞
因为是OLTP和OLAP兼顾，小的时候就侧重OLTP，大的时候就侧重OLAP
业务系统里这样子。
如果是跑数据或者程序段里，可以稍大一些
如果不考虑向其他数据库同步数据的话，可以提高本地数据库的事务大小限制。
同时可以考虑是用BATCH 语句将一个 DML 语句拆成多个语句在内部执行。
自己测最佳值啊，你说的几千条并不是数据库支持的上线， tidb一次insert几十万也没啥问题。
我们这里搞出来几百万的条的事务也没啥
1 个赞
TiDB确实对单个事务的大小有限制,但实际上默认限制并不是1000行,而是100MB。这个限制可以通过配置参数txn-total-size-limit 来调整,最大可以设置到10GB。
限制事务大小的主要原因是:
- 优化事务内存使用:TiDB的事务会先在内存中缓存变更,过大的事务会占用大量内存。
- 保证分布式一致性:较小的事务更容易在分布式环境中保证一致性。
- 避免长时间锁定:大事务可能会长时间占用锁,影响并发性能。
MySQL也一样，主要还是复制同步的原因。 Oracle的同步主要不是基于事务的，是redo的物理log，锁机制也比较好，所以相对事务大小不是什么问题
201.5课程里的内容
1.分布式是多个节点写入成功才可以，大事物会有较高等待，写入表想更快，需要设置shard bit的，避免热点。
2.根据主键分页删除，应该是为了减少mvcc多版本的影响，避免越删越慢。
事务调小，并发调大，应该会比大事务快很多，tikv资源都可以用的更多更均衡。
其实MySQL虽然没有明文限制过，但是一次更新太多行会导致undo回滚段暴涨，你这个可以考虑按照id区间更新，但是可以开启多个并发执行
默认单个sql大小的内存限制是1G，可以修改该变量，但是也不建议太大，否则可能出现内存溢出的情况
TiDB官方文档中提到，单个事务包含的SQL语句不超过5000条，每个键值对不超过6MB，键值对的总数不超过300,000，键值对的总大小不超过100MB
现在还是得拆吧，现在基本就内存限制，你要内存够，能执行个几十 GB 的事务，后边估计 TiDB 会支持更大事务（上百 GB）
需求上如果能确认，写入的表只有自己在进行，可以用bach拆分。这样可能可以降低一些工作量
https://docs.pingcap.com/zh/tidb/stable/sql-statement-batch#batch
非事务 DML 语句是将一个普通 DML 语句拆成多个 SQL 语句（即多个 batch）执行，以牺牲事务的原子性和隔离性为代价，增强批量数据处理场景下的性能和易用性。