Tableau对接Redshift游标执行耗时不均及回滚日志相关疑问

1. 游标执行耗时过长的已知诱因 #

从你提供的svl_qlog日志可以看到所有游标都是单次fetch 10万行，出现耗时波动的常见诱因如下：

• 宽表批量取数开销过大：你提到查询涉及列数较多，单批次10万行的数据序列化、网络传输开销会比窄表高很多，当数据分布不均匀时部分批次扫描的数据量远大于平均值，就会出现耗时陡增
• Redshift集群资源争抢：所有查询都运行在主集群，若同一时段集群有其他计算/IO密集型任务占用资源，游标查询会被调度优先级限制，导致执行时长被拉长
• 事务回滚带来的锁等待：日志中频繁出现的Undo操作会持有对应表的写锁，后续访问该表的游标fetch操作必须等待锁释放才能执行，直接导致耗时变长
• 表结构不合理：若查询的表未配置合理的distkey、sortkey，宽表查询需要跨节点扫描大量冗余数据块，也会带来明显的耗时波动

2. 责任方判定 #

该问题属于两侧默认配置适配不当导致的，不属于单方责任：

• Tableau侧默认的游标批量取数大小（10万行）没有针对宽表场景做自适应，是诱发耗时波动的原因之一
• Redshift侧的资源调度、锁机制放大了耗时波动，同时回滚操作没有做优先级优化也加剧了问题
  你可以通过调整配置缓解问题：在Tableau数据源的自定义参数中调低FetchBufferSize到1万~5万行，同时在Redshift侧为tableau用户配置独立的查询队列，优化查询涉及的宽表结构。

3. Undoing 1 transactions on table 1728722 with current xid 361类日志的含义 #

这是Redshift的事务回滚日志，含义是当前事务因异常终止（常见原因包括锁冲突、资源不足被集群强制终止、客户端主动断开连接），需要撤销该事务对指定表的所有未提交修改，保证数据一致性。
你日志中这类回滚操作均出现在两次游标fetch操作之间，说明前一次游标取数的关联事务执行失败，回滚过程持有的写锁阻塞了后续的游标读操作，也是你观测到部分游标fetch耗时过长的直接诱因。

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