8004 - Transaction is too large, size: 1073791624

johnwa-CD · 2021 年9 月 28 日 08:55

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
5.0.2

【概述】场景 + 问题概述
提示事务过大

【背景】做过哪些操作

【现象】业务和数据库现象
事务过大

【问题】当前遇到的问题
语句
update FbAd a,FbAdCreative b set a.GroupId = ifnull(b.GroupId,0) where a.AdCreativeId = b.AdCreativeId and a.GroupId = 0;

两个表关联更新,常见操作
desc查看执行计划

Update_6	N/A	root
└─IndexHashJoin_16	49991.58	root
├─TableReader_49(Build)	44161.00	root
│ └─Selection_48	44161.00	cop[tikv]
│ └─TableFullScan_47	44161.00	cop[tikv]	table:a
└─IndexLookUp_13(Probe)	1.13	root
├─Selection_12(Build)	1.13	cop[tikv]
│ └─IndexRangeScan_10	1.13	cop[tikv]	table:b, index:IX_AdCreativeId(AdCreativeId)
└─TableRowIDScan_11(Probe)	1.13	cop[tikv]	table:b

才四万行记录啊,
select count(1) as ccount from FbAd a left join FbAdCreative b on a.AdCreativeId = b.AdCreativeId
行数:44162

8004 - Transaction is too large, size: 1073791624

【业务影响】

【TiDB 版本】 5.0.2

【应用软件及版本】

【附件】相关日志及配置信息

TiUP Cluster Display 信息
TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)

TiDB-Overview Grafana监控
TiDB Grafana 监控
TiKV Grafana 监控
PD Grafana 监控
对应模块日志（包含问题前后 1 小时日志）

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

yiqing2021 · 2021 年9 月 28 日 10:00

在 TiDB 的早期版本中，一个语句每 20000 行进行一次提交。新版本的 TiDB 默认在一个事务中提交所有行。从 TiDB 4.0 及以前版本升级后，可能出现 ERROR 8004 (HY000) at line 1: Transaction is too large, size: 100000058 错误。
要解决该问题，建议调大 tidb.toml 文件中的 txn-total-size-limit 值。如果无法增加此限制，还可以将 tidb_dml_batch_size 的值设置为 20000 来恢复升级前的行为。

spc_monkey · 2021 年9 月 28 日 10:16

leeray · 2021 年9 月 28 日 14:51

昨天刚刚遇到这个问题，默认事务100M太小了。binlog同步的时候，rpc消息太大直接导致tidb挂掉了。

johnwa-CD · 2021 年9 月 29 日 01:46

这个是 2GB啊

update FbAd a,FbAdCreative b set a.GroupId = ifnull(b.GroupId,0) where a.AdCreativeId = b.AdCreativeId and a.GroupId = 0

8004 - Transaction is too large, size: 2147535123
时间: 70.097s

johnwa-CD · 2021 年9 月 29 日 01:46

调大到 2GB还是报错
update FbAd a,FbAdCreative b set a.GroupId = ifnull(b.GroupId,0) where a.AdCreativeId = b.AdCreativeId and a.GroupId = 0

8004 - Transaction is too large, size: 2147535123
时间: 70.097s

songxuecheng · 2021 年9 月 29 日 01:51

最大调整为10G,如果超过建议分批更新

johnwa-CD · 2021 年9 月 29 日 02:08

我感觉这个很奇怪,这表才四万行.没有 2GB 这么大的数据啊.我就更新个 Id INT类型的

johnwa-CD · 2021 年9 月 29 日 02:08

我感觉这个很奇怪,这表才四万行.没有 2GB 这么大的数据啊.我就更新个 Id INT类型的

songxuecheng · 2021 年9 月 29 日 02:09

执行计划拿出来看下

johnwa-CD · 2021 年9 月 29 日 02:12

上面发过了,我再贴一次

└─IndexHashJoin_16	51097.25	root
├─TableReader_49(Build)	44165.00	root
│ └─Selection_48	44165.00	cop[tikv]
│ └─TableFullScan_47	44165.00	cop[tikv]	table:a
└─IndexLookUp_13(Probe)	1.16	root
├─Selection_12(Build)	1.16	cop[tikv]
│ └─IndexRangeScan_10	1.34	cop[tikv]	table:b, index:IX_AdCreativeId(AdCreativeId)
└─TableRowIDScan_11(Probe)	1.16	cop[tikv]	table:b

songxuecheng · 2021 年9 月 29 日 02:19

和条数无关,KV entry 的总大小不超过建议你继续调大参数试一下

johnwa-CD · 2021 年9 月 29 日 02:20

太扯了吧?
这个不是只更新一个 Id么 ?我已经调大到10G了.依然无法执行…

songxuecheng · 2021 年9 月 29 日 02:21

txn-total-size-limit 修改的这个参数嘛？

johnwa-CD · 2021 年9 月 29 日 02:25

songxuecheng · 2021 年9 月 29 日 02:27

10G的出错截图一下。还有tidb的日志

johnwa-CD · 2021 年9 月 29 日 02:27

什么日志呢?哪个的?

songxuecheng · 2021 年9 月 29 日 02:28

执行这个sql的tidb节点的tidb.log

johnwa-CD · 2021 年9 月 29 日 02:36

songxuecheng · 2021 年9 月 29 日 02:37

这是2G的时候你修改参数之后重新reload了吗