Informix DELETE查询需要很长时间

问题描述：

在生产中，我面临着这个问题。Informix DELETE查询需要很长时间

有一个delete需要很长时间才能执行并最终抛出-243的SQL错误。
我使用onstat -g得到了查询。

有什么方法可以找出是什么导致它花费这么多时间，最后出错？

它使用COMMITTED READ隔离。

这也导致了很高的Informix CPU使用率。

编辑

环境 - 在Solaris

我没有看到相关的索引或应用程序逻辑的任何问题，但我怀疑一些Informix的腐败的Informix 9.2。
在执行此DELETE查询时，会话在不同的表上保存8个锁。
但是，我没有看到delete执行表上的任何锁。

会是这样吗，informix无法锁定表格？

您是否试过将'DELETE FROM TABLE WHERE ...'作为'SELECT * FROM Table WHERE ...'（适用于所有列的任何合适的子集）并查看了查询计划？这个工作有多快？表格是否具有斑点列或智能斑点列？ DELETE的查询计划是什么？它如何与SELECT计划进行比较？是否有索引缺失可以加快速度？桌上有多少个索引？有那么多的减少索引的数量会提高性能？哪个版本的Informix？在哪个平台上运行？ – 2013-03-07 19:30:09

表在2列上具有组索引，删除也基于该2列。 – cppcoder 2013-03-08 07:31:53

答

DELETE不关心你的隔离级别。您正在获取243，因为当您尝试运行删除操作时，另一个进程正在锁定该表。

我把你删除成SP，并承诺每X个记录：

CREATE PROCEDURE tmp_delete_sp (
    p_commit_records INTEGER 
) 
RETURNING 
    INTEGER, 
    VARCHAR(64); 

DEFINE l_current_count INTEGER; 

SET LOCK MODE TO WAIT 5; -- Wait 5 seconds if another process is locking the table. 

BEGIN WORK; 

FOREACH WITH HOLD 
    SELECT ..... 

    DELETE FROM table WHERE ref = ^^ Ref from above; 

    LET l_current_count = l_current_count + 1; 

    IF (l_current_count >= p_commit_records) THEN 
    COMMIT WORK; 
    BEGIN WORK; 
    LET l_current_count = 0; 
    END IF; 

END FOREACH; 

COMMIT WORK; 

RETURN 0, 'Deleted records'; 
END PROCEDURE;

一些语法问题存在，但它是你一个很好的起点块。请记住，随着您使用更多逻辑日志，插入和更新的速度会逐渐变慢。

答

Informix重新启动非常多次，导致informix不稳定。
这是根本原因。

Informix DELETE查询需要很长时间

相关推荐