sql - 巨大表的 MSSQL 游标无法分配空间

Question

我们正在尝试设置一个游标来遍历同一巨大表(超过 1.5 亿条记录)的两个“实例”之间的连接生成的记录。

出现如下异常信息:

Could not allocate space for object 'dbo.SORT temporary run storage: 165282123350016' in database 'tempdb' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

你们知道这是什么原因吗？或者如何让下面的查询更高效？

我发现它发生在 DECLARE CURSOR 和第一个 FETCH NEXT 之间的某处，但我还不知道它是否介于...

• DECLARE CURSOR 和OPEN

或之间

• OPEN 和第一个 FETCH NEXT。

更多细节:sql语句如下:

DECLARE cData CURSOR LOCAL FORWARD_ONLY READ_ONLYFOR  SELECT ...  FROM HugeTable HT1 JOIN HugeTable HT2 ON ..   JOIN Table3 ON .. JOIN Table4 ON .. JOIN Table5 ON ..  WHERE ...  ORDER BY HT1..., HT1...INSERT INTO SysLog (Description) VALUES ('A')OPEN cDataBEGIN TRANSACTION ProcessData  -- Currently trying new logging here:  -- INSERT INTO SysLog (Description) VALUES ('B')   FETCH NEXT FROM cData INTO ...  INSERT INTO SysLog (Description) VALUES ('C')  ... etc.

我收到的最后一条日志消息是“A”，然后一小时后它失败并显示上述消息，从未到达“C”。我现在正在尝试在“B”点进行日志记录。

---

根据要求，我发布了准确的 sql 表达式:

DECLARE cSource CURSOR LOCAL FORWARD_ONLY READ_ONLYFOR    SELECT MD.sFieldName,         MD.sFieldValue,         TR.sTargetDataType,        MD2.sFieldValue AS sUniqueID,        TR.sTargetTableName,        TR.sTargetFieldName,        I.iRefCustomerID,         I.iInterfaceID,         IL.iRefInterfaceSessionID    FROM MasterData MD    JOIN MasterData MD2        ON MD.iRowIndex = MD2.iRowIndex        AND MD.iBatchNumber = MD2.iBatchNumber        AND MD.sTableName = MD2.sTableName         AND MD2.sFieldName = 'sUniqueID'    JOIN SourceTargetRelation TR        ON MD.sFieldName = TR.sSourceFieldName        AND MD.sTableName = TR.sSourceTableName    JOIN InterfaceLog IL        ON IL.iInterfaceLogID = MD.iBatchNumber    JOIN Interface I        ON I.iInterfaceID = IL.iRefInterfaceID        AND TR.iRefSystemID = I.iRefSystemID    WHERE        MD.iBatchNumber = @iBatchNumber    ORDER BY MD.sTableName, MD.iRowIndex

---

在 Quassnoi 的更新答案之后，我也将原始索引发布在表格上:

我在该表上有一个非聚集索引，其中包含列 iBatchNumber、sFieldName、sTableName、iRowIndex。该索引将 sFieldValue 作为包含的列。

---

正如 Quassnoi 所建议的(我想我现在明白为什么了)我已经更改了索引以具有以下顺序的列:iBatchNumber、sTableName、iRowIndex ，字段名。我使用 sFieldValue 作为包含的列。执行计划不再包含任何SORT，并且执行计划中的步骤数不到原来的一半，我希望也更快......

Answer 1

Do any of you know the reason for this? Or how to make the query below below more efficient?

您的查询使用 ORDER BY。

这需要排序，排序需要临时空间。你不在这个空间内。

为避免这种情况，请在您的大表上创建一个复合索引:(col_filter_1, col_filter_2, col_order_1, col_order_2)，其中 col_filter_n 是您筛选的列，并且col_order_n 是您排序的列。

这样的索引可用于过滤和排序过滤结果。

如果您发布您的实际查询(即您过滤和排序的表达式)，我可能会更准确地告诉您如何创建这样的索引。

更新:

从您的查询中，我可以看出您需要 (iBatchNumber, sTableName, iRowIndex, sFieldName) 上的索引(按此顺序)。

如果您使 MD2 在连接中处于领先地位，它也可能会有所帮助:

WHERE
    MD2.iBatchNumber = @iBatchNumber
ORDER BY
    MD2.sTableName, MD2.iRowIndex

查看执行计划并确保未使用SORT 操作。