tencent cloud

TDSQL Boundless

文档TDSQL Boundless故障处理事务相关事务过大

事务过大

Download
聚焦模式
字号
最后更新时间： 2026-07-17 16:33:33

现象描述

TDSQL Boundless 实例在运行过程中，业务侧出现事务过大相关报错，可能伴随以下现象：
应用程序日志中出现事务写入大小超限的错误提示。
应用程序日志中出现事务参与者数量超限的错误提示。
实例监控中 SQL 失败数指标升高。
大事务执行期间，内存利用率升高，其他业务请求响应变慢。
大事务执行期间，可能触发锁等待或死锁。
您可在 TDSQL Boundless 控制台的实例详情 > 监控告警 > 指标监控页面查看 SQL 失败数、内存利用率、每秒处理的事务数等指标。

可能原因

事务过大通常由单事务写入数据量过多、参与者数量超限或批量操作未分批导致。可能原因如下：
序号
可能原因
1
单个事务写入数据量过大，超过 tdstore_max_txn_size 限制，导致事务被拒绝写入。
2
单个事务涉及的参与者（复制组）数量超过 tdsql_transaction_max_participants 限制。
3
批量导入操作（如 LOAD DATA、INSERT ... SELECT）未分批执行，单次操作数据量过大。
4
长事务执行时间过久，持有锁和内存资源时间过长，影响其他业务。
5
ALTER TABLE 等大表 DDL 操作产生大量数据拷贝，事务过大。

解决思路

针对不同原因，解决思路如下：
可能原因
解决思路
单事务写入量过大
拆分大事务为多个小事务，通过控制台调整 tdstore_max_txn_size 参数。
参与者数量超限
减少单事务涉及的表和分区数量，分批执行跨表操作。
批量导入未分批
将大批量导入拆分为多批次，每批次控制在合理数据量内。
长事务持锁过久
优化事务内 SQL 执行效率，缩短事务范围，设置合理的超时时间。
DDL 数据拷贝过大
确认 tdsql_split_trans_during_alter_copy 参数已开启，使 DDL 自动拆分事务。

处理步骤

步骤1：查看监控指标

1. 登录 TDSQL Boundless 控制台，在实例列表中单击目标实例 ID，进入实例详情页。
2. 选择监控告警 > 指标监控页签，查看以下指标的变化趋势：
监控指标
说明
关注点
SQL 失败数
每秒失败的 SQL 数量
事务超限时失败数会突增
内存利用率
实例内存使用率
大事务执行期间内存是否飙升
每秒处理的事务数
每秒事务提交数
事务数是否异常下降
慢查询数
每秒慢查询数量
大事务是否导致其他查询变慢
活跃线程数
当前活跃线程数
是否有线程长时间被大事务阻塞
重点关注 SQL 失败数突增和内存利用率飙升的时间点，与批量任务或大事务执行时间是否吻合。

步骤2：查看大事务信息

通过系统视图查看当前是否存在大事务，以及大事务的资源占用情况。
1. 连接数据库实例，执行以下 SQL 查看当前的大事务信息。
SELECT
    replication_group_id,
    transaction_id,
    disk_usage_bytes,
    memory_usage_bytes,
    rollback,
    destroyed
FROM information_schema.TDSTORE_LARGE_TXN
WHERE destroyed = 0
ORDER BY disk_usage_bytes DESC
LIMIT 20;
该视图展示当前活跃的大事务信息，字段说明如下：
replication_group_id：复制组 ID。
transaction_id：事务 ID。
disk_usage_bytes：磁盘使用量（字节），反映事务数据在 SST 文件中的大小。
memory_usage_bytes：内存使用量（字节），反映事务在 MemTable 中的大小。
rollback：是否已回滚。
destroyed：是否已销毁。
2. 若存在 disk_usage_bytes 或 memory_usage_bytes 值较大的事务，记录其 transaction_id，用于后续排查。
3. 执行以下 SQL 查看当前正在执行的会话，定位大事务对应的 SQL。
SELECT
    ID,
    USER,
    HOST,
    DB,
    COMMAND,
    TIME,
    STATE,
    INFO
FROM information_schema.PROCESSLIST
WHERE COMMAND != 'Sleep'
ORDER BY TIME DESC
LIMIT 20;
重点关注 TIME 值较大的会话，这些会话可能正在执行长事务或大事务。

步骤3：终止大事务（可选）

若大事务已严重影响业务正常运行，可终止对应会话以释放资源。
1. 根据步骤2查到的大事务信息，结合步骤2第3步 PROCESSLIST 查询结果中 TIME 值较大的会话，通过执行时间、SQL 文本等信息综合定位大事务对应的会话 ID。
2. 执行以下 SQL 终止该会话。
KILL <会话ID>;
警告：
KILL 操作会中断正在执行的事务并触发回滚，回滚过程中可能继续占用资源。请确认目标会话后再执行，避免误杀正常业务会话。

步骤4：调整单事务内存上限

若业务确实需要执行较大事务，可通过控制台调整 tdstore_max_txn_size 参数，详细操作请参见 设置实例参数。
默认值为1GB。若单事务数据量超过此限制，可适当调大。
调大后需关注实例内存利用率，避免多个大事务并发执行导致内存不足。
注意：
调大 tdstore_max_txn_size 会增加单事务可占用的内存，在高并发场景下可能导致内存压力增大。
建议优先通过拆分事务解决，仅在业务确实需要大事务时才调整此参数。

步骤5：优化批量导入操作

批量导入是导致事务过大的常见原因，建议从业务层面优化批量操作。
1. 分批导入：将大批量数据拆分为多个批次，每批次使用独立事务提交。
例如，将 INSERT INTO ... SELECT ... 拆分为多个带 LIMIT 的子查询。
每批次的数据量建议控制在 tdstore_max_txn_size 限制以内。
2. 调整批量导入参数：若使用 LOAD DATA 等批量导入方式，可通过控制台调整以下参数，详细操作请参见 设置实例参数。
tdstore_bulk_load_total_merge_buffer_size：批量导入合并缓冲区总大小，控制批量导入过程中的内存使用。
tdstore_bulk_load_merge_chunk_size：批量导入单个合并块大小，控制单次归并排序的数据量。

步骤6：优化长事务

长事务会长时间持有锁和内存资源，增加事务过大的风险。
1. 缩短事务范围：
事务中只包含必要的数据库操作，将非数据库操作（如远程调用、文件 IO）移到事务外部。
尽早提交事务，避免事务长时间处于未提交状态。
2. 设置合理的超时时间：通过控制台调整以下参数，避免长事务无限期占用资源，详细操作请参见 设置实例参数。
max_execution_time：SELECT 语句的最大执行时间（毫秒），设置为合理值可防止慢查询长时间运行。
wait_timeout：连接空闲超时时间（秒），超过此时间未活动的连接将被自动关闭。

步骤7：确认 DDL 事务拆分

ALTER TABLE 等大表 DDL 操作会进行数据拷贝，可能产生大事务。TDSQL Boundless 支持在 DDL 期间自动拆分事务，避免单事务过大。请根据业务需要调整以下参数，详细操作请参见 设置实例参数。
tdsql_split_trans_during_alter_copy 参数：确认该参数值为 ON。若为 OFF，建议修改为 ON，使 DDL 数据拷贝期间自动拆分小事务提交。
tdsql_bulk_commit_records 参数：控制 DDL 拷贝期间每批提交的记录数。默认值为3000，可根据表数据量适当调整。

步骤8：调整事务保活时间

若业务存在长时间执行的合法大事务（如大数据量 ETL），需确保事务保活时间足够长，避免事务因超时被自动释放。
调整 tdsql_txn_keep_alive_lease_sec 参数。该参数控制 TDStore 在多久未收到事务心跳后释放事务上下文，默认值为 3600 秒（1 小时）。若大事务执行时间超过此值，可适当调大。详细操作请参见 设置实例参数。
注意：
调大事务保活时间会增加事务上下文的内存占用时间。若实例中同时存在大量长事务，可能导致内存压力增大。请根据实际业务需求合理设置。

预防措施

为避免事务过大问题反复发生，建议采取以下预防措施：
配置告警策略：在控制台为 SQL 失败数和内存利用率配置告警，及时发现事务过大问题。
规范事务设计：制定事务开发规范，控制单事务的数据量和执行时间，避免大事务和长事务。
分批处理批量任务：大批量数据导入和更新操作必须分批执行，每批次数据量控制在合理范围内。
监控事务指标：定期关注每秒处理的事务数和 SQL 失败数指标，及时发现事务异常。
DDL 操作规范：大表 DDL 操作前确认 tdsql_split_trans_during_alter_copy 已开启，避免 DDL 产生过大事务。
上一篇: 慢查询数过高下一篇: 应用死锁

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈