也不能设置太大，否则单个sql占用资源过多，容易导致内存溢出，影响其他性能
但是tidb dishboard确实记录消耗十几G内存，难道这个不准吗
这个要看你的机器系统配置和属性的配置，消耗十几G内存不一定都是sql消耗的，如果你的单个sql设置了阈值，那么超过阈值sql就报错了。
问题1：
事务的大小容量可以理解为你要操作变更的数据大小。
问题2：
如果你要一次性操作大量数据，超过支持的最大值，比如要一次性update 100GB的数据且要求放在事务里完成，这个时候事务会中断回滚，无法执行。
这里要考虑到分布式系统，维持一个大事务的代价是很高的，不仅事务本身执行效率低下，同时会挤兑集群资源、影响其他业务正常访问，所以非常有必要限制事务的大小。
所以从安全和高效的角度看，解决的办法是避免一次性操作太多数据，即避免操作大事务。
可以通过程序或脚本来批量执行。
问题3：
所以对大表而言要把一个更新分拆成很多个事务执行，不管你是用存储过程还是脚本，本质都是一样的，需要一些额外的操作来辅助完成。TiDB 的最新信创版本（平凯数据库）是支持存储过程的，但是社区版需要外部脚本来协助完成。
要规划好
回答很好，我也可以理解。但是我看到我们有一些分析系统的开发人员喜欢做某些表的批量更新，他们经常做的事情就是把一个大表truncate掉，然后把新的数据从另外几个表中通过SQL合成一个表中insert 过来，我经常看到一个insert就几个G的数据。TiDB本身也可以当成数仓，如果限制事务大小，必然也会限制“不太精通”数据库开发的人员使用。
的确如此，对于类似这样的场景我们只是都是通过外部程序，比如spark 、flink等结合完成。
如果希望能用一条sql实现，最佳实践是放弃事务的保证，使用非事务方式使得完成SQL的执行，然后再去检查数据一致性。
通过这样操作，也能一定程度上完成业务的需求。
好的，我知道了，等我再看看TiSpark再做评论。
也可以临时调整内存限制参数啊，只要不OOM就行了吧
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。