Trino Python客户端循环调用cursor.fetchone()触发ABANDONED_QUERY错误

问题描述 #

为降低脚本内存占用，采用循环调用cursor.fetchone()的方式逐行处理Trino数据，但运行约30分钟后脚本退出，抛出以下错误：

TrinoUserError(type=USER_ERROR, name=ABANDONED_QUERY, message=... Query results have not been accessed since 2023-10-13T17:10:23.546Z: currentTime 2023-10-13T17:15:23.774Z"

异常中“accessed since”的时间戳恰好是脚本启动时间，且提示“5分钟内未访问查询”，但脚本实际成功运行了30分钟，需明确该异常的触发原因。

已尝试操作 #

• 使用Trino Python客户端的cursor.fetchone()循环遍历数据库表，成功运行30分钟
• 期望遍历完成后程序正常退出
• 实际收到“程序启动5分钟内未访问查询”的错误

异常原因分析 #

1. Trino服务端闲置超时机制触发
   Trino服务端默认会设置查询结果闲置超时时间（通常为5分钟），若服务端检测到客户端在指定时间内未主动拉取新结果，就会标记查询为ABANDONED并终止。这里的“未访问”并非指客户端完全没调用fetchone()，而是存在两种核心场景：

   • 单条数据处理耗时过长：逐行处理时，单条数据的业务逻辑耗时超过服务端超时阈值，导致两次向服务端拉取结果的间隔超时。服务端从最后一次拉取请求的时间开始计时，一旦超时就触发终止，但客户端仍在处理本地数据，直到后续请求新结果时才收到延迟的错误响应。
   • 客户端预取缓存掩盖了服务端超时：Trino Python客户端的cursor默认会预取一批结果缓存到本地（由arraysize参数控制）。当本地缓存未耗尽时，客户端不会向服务端发起新请求，此时服务端会判定客户端未访问结果并开始计时超时。等本地缓存处理完毕再请求时，服务端早已终止查询，客户端才抛出之前触发的超时错误，错误中的时间戳就是服务端开始计时的时间（即客户端最后一次请求服务端的时间，也就是脚本启动时的第一次请求）。

2. 客户端与服务端状态不同步
   客户端的本地缓存机制会让服务端误以为客户端已停止访问结果，而客户端实际还在处理缓存数据，这种状态差导致服务端提前触发超时，但客户端延迟到缓存耗尽后才收到错误，最终出现“运行30分钟却收到5分钟超时”的矛盾现象。

解决建议 #

• 调整服务端超时配置：若有权限，可修改Trino集群的query.max-idle-time参数，延长闲置超时阈值，但需注意避免占用过多集群资源。
• 优化客户端拉取策略：
  • 减小cursor.arraysize的值，降低预取结果的数量，让客户端更频繁地向服务端发起拉取请求，避免服务端触发超时。
  • 优化单条数据的处理逻辑，缩短每次fetchone()后的耗时，确保两次拉取请求的间隔小于服务端超时时间。
• 主动维持查询活跃：在处理循环中，定期调用客户端提供的活跃保持接口（如部分版本支持的cursor.ping()），告知服务端查询仍在进行。

内容的提问来源于stack exchange，提问作者blake27182