Informix DELETE 查询需要很长时间答案

【问题标题】：Informix DELETE query taking long timeInformix DELETE 查询需要很长时间
【发布时间】：2013-03-07 05:05:51
【问题描述】：

在生产中，我遇到了这个问题。

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

有什么方法可以找出导致它花费这么多时间并最终出错的原因？

它使用COMMITTED READ隔离。

这也会导致 Informix cpu 使用率过高。

编辑

环境 - Solaris 上的 Informix 9.2

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

会不会是，informix 无法锁定桌面？

【问题讨论】：

您是否尝试将DELETE FROM Table WHERE ... 作为SELECT * FROM Table WHERE ... 运行（对于所有列的任何合适的子集）并查看查询计划？它的工作速度有多快？表是否有 blob 列或智能 blob 列？ DELETE 给出的查询计划是什么？它与 SELECT 计划相比如何？是否缺少可以加快速度的索引？表上有多少个索引？减少索引数量会提高性能吗？哪个版本的 Informix？在哪个平台上运行？
表在 2 列上有一个组索引，删除也基于这 2 列。

标签： informix

【解决方案1】：

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;

那里存在一些语法问题，但这对您来说是一个很好的起点。请记住，当您使用更多逻辑日志时，插入和更新会逐渐变慢。

【讨论】：

【解决方案2】：

Informix 多次不正常重启，导致 Informix 不稳定。
这是根本原因。

【讨论】：