首页 > 解决方案 > Sybase:从另一个存储过程中调用的存储过程太慢

问题描述

我正在为 Sybase 数据库编写存储过程。我使用 Sybase Central 16.0 作为我的开发环境。我使用的机器运行 Microsoft Windows Server 2012 R2 Standard,并在 2.8GHz CPU 上运行 16GB RAM。

我的存储过程使用游标遍历表中的记录,该表有大约 400,000 条记录。每条记录都被增量写入一个LONG VARCHAR变量,并且每第 N 条记录 proc 将对变量运行一个 MD5 哈希值并将该值存储在一个单独的表中。

TABLE_NAME, DATE_TIME_RAN, FROM_RECORD, TO_RECORD, HASH_VALUE

如果我只运行存储过程来将此表作为 SQL Anywhere 中的 SQL 块进行散列(例如:)BEGIN ... <hash the table here> ... END;,它将遍历所有记录并在大约两分钟内成功完成。但是,如果我将此存储过程作为嵌入命令运行在另一个存储过程(例如:)中,CALL <MY_SCHEMA>.<MY_STORED_PROCEDURE>则它永远不会完成。

为什么从另一个存储过程中运行存储过程(在同一数据集上)的性能会有所不同?

标签: sqlstored-proceduressybasesqlanywheresqlperformance

解决方案


设法找到一个更好的解决问题的方法,而无需通过表格拖网。我想我会在这里为可能面临类似问题的任何人发布解决方案。

存储过程的要求是一次遍历一个大表一行,将行中每一列的内容连接成一个字符串并将其分配给一个变量。每 N 行此变量的值将被写入一个单独的表。以前我一直使用游标来执行此操作,但我们团队的一位开发人员发现了一种使用 WITH 子句的更快方法。

INSERT INTO <MY_SCHEMA>.<MY_TABLE_THAT_WILL_CONTAIN_THE_CONCATENATED_VALUES_OF_EVERY_N_ROWS>
WITH 
    CONCATENATE_ROWS AS (
            SELECT RANK() OVER (ORDER BY <PRIMARY_KEY_COLUMN>) AS ROWID, <PRIMARY_KEY_COLUMN>, <COLUMN_1> || '' || <COLUMN_2> || '' || ... <COLUMN_N> AS ROW_DETAIL
            FROM <MY_TABLE_THAT_I_AM_QUERYING> 
            ORDER BY <PRIMARY_KEY_COLUMN>
    ), 
    GROUPED_ROWS AS (
            SELECT (((CONCATENATE_ROWS.ROWID-1)/ <number of rows I want to concatenate, e.g.: 10>)+1) AS GROUPID, CAST(LIST(CONCATENATE_ROWS.ROW_DETAIL, '' ORDER BY <PRIMARY_KEY_COLUMN>) AS VARCHAR(4000)) AS CONCAT_DETAILS
             FROM CONCATENATE_ROWS 
             GROUP BY (((CONCAT_ORDERS.ROWID-1)/ <number of rows I want to concatenate, e.g.: 10>)+1)
    )
SELECT <Whatever columns I want to insert into <MY_TABLE_THAT_WILL_CONTAIN_THE_CONCATENATED_VALUES_OF_EVERY_N_ROWS>> 
FROM GROUPED_ROWS;

推荐阅读