我们有一个性能问题的红移集群。当在集群上运行某些查询时，在查询计划中有一个中间步骤<SQL_CUR7">中Fetch 200。这一步会导致查询挂起并阻塞集群。我们还没有定义这个光标，它似乎是由红移预先定义的。有人知道这种游标是做什么的吗?如果这可能是我们性能问题的原因呢?
这个名称SQL_CUR7看起来像Tableau使用的命名，但它可能来自使用相同命名或正在复制的其他工具或用户。通常Tableau一次会获取10,000行，所以它可能不是Tableau。关键是FETCH不是你的问题——它可能是在FETCH背后的查询。
让我们从一些背景开始。当你运行一个查询(select…)时，查询的结果会被发送回给你——所有的结果，不管有多大。来自"红移"的大量数据可能会淹没小型计算机，使网络瘫痪。而不是一个"光标"。可以声明，并且查询的结果可以临时存储在那里(在本例中存储在Redshift leader节点上)。FETCH命令读取游标的内容，取出指定数量的行。这样，阅读器就不会被超出其处理能力的数据所淹没。可以重复读取，直到读取游标的所有行。
游标由DECLARE语句定义，该语句还指定要运行的查询来填充游标。但是，在第一次对游标进行FETCH操作之前，查询不会运行。后续的FETCH只是提取第一次FETCH执行时填充在游标中的更多数据。这样做的缺点是，它看起来就像取回是正在运行的东西，它不会告诉你发生了什么。它是在DECLARE语句中定义的正在运行的SQL，您需要找出这个SQL是什么，以了解发生了什么。
追溯这个并不太难。游标仅在事务打开期间存在。这意味着FETCH和DECLARE在同一个事务(xid)中。因此，找到'Fetch 200 in "SQL_CUR7"'的xid，并使用它来查找系统表SVL_STATEMENTTEXT中此事务(xid)中发出的所有语句。(xid可以在一段时间后重用，因此您可能希望只查看fetch执行前后的时间窗口。)您应该看到一条定义了"SQL_CUR7"- DECLARE SQL_CUR7"…-这是当读取发生时正在运行的SQL。
现在你看到了这个SQL的事情可能会开始有意义，为什么事情变得过载。查询可能会很糟糕，并且与其他所有内容交叉连接。它可以用中间结果填满磁盘。查询可能会返回大量数据，并且会使需要缓冲的数据使leader节点过载。您可能需要做一些诊断工作，但至少现在您有了需要分析的代码。