【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】社区版4.2.1.1 单机部署
【问题描述】交互语言为go，xorm mysql框架，当天晚上6点左右进行事务begin 批量删除、批量写数据1、数据2、数据3 commit 。第二天晚上6点左右再次进行事务，发现删除正常、数据1正常(数据量较小)、数据2正常(数据量较小)、数据3卡住无反应(大概几十万条)，但是查询是正常的，且netstat tcp连接都正常。此时重启应用程序(不是observer)，重新写入正常，时间大概在11/17 17:45:31。怀疑是wait_timeout或inactive_timeout，默认是8小时超时导致，测试环境修改为10秒后不能复现此场景
【复现路径】大概12个小时必现，每次重启后恢复正常
【附件及日志】 https://upfile.live/zh-cn/files/6c167ccf
【操作系统】 centos7.2
[安装参数] mini-local-example.yaml memory_limit: 20G system_memory: 2G datafile_size: 4G datafile_next:4G cpu_count:4 目前系统只有一个sys租户，一个用户，没有其他租户
用户问题: “在OceanBase社区版4.2.1.1中使用Go语言和xorm框架进行事务批量操作时，写入操作卡住但查询正常，如何解决？”
推荐使用 obdiag 工具进行日志采集，以便进一步诊断写入操作卡住的原因。以下是推荐的命令：
日志采集场景: 写入操作卡住
日志采集命令: obdiag gather scene run --scene=observer.write_stuck
为了能够更准确地定位问题，请您提供以下信息：
- 您的操作系统版本是什么？
- 您可以提供事务的具体执行语句吗？
- 在事务执行过程中，是否有异常的日志输出？
- 这个问题是一直存在还是偶尔出现？
- 当前OceanBase集群的配置情况如何（例如：服务器硬件配置、集群规模等）？
- 您是否启用了任何特定的参数或设置，与默认配置有所不同？
请您运行上述命令并提供采集到的日志压缩包，我们将根据日志进一步分析问题。
附上敏捷诊断工具 obdiag 使用帮助链接
事务大概执行时间是多长。
70秒左右
更新了下描述，数据3写入不是失败，是卡住没反应
需要提供一下该事物trace id的observer日志。