Question

我使用postgres与hibernate，我有两个SQL表。 “TABLE_2”与“TABLE_1”具有manyToOne关系。

CREATE TABLE "TABLE_1"
(
  "ID" bigint NOT NULL,
  "VALUE" bigint NOT NULL,
  CONSTRAINT "PK_TABLE_1 " PRIMARY KEY ("ID" ),
)

CREATE TABLE "TABLE_2"
(
  "ID" bigint NOT NULL,
  "TABLE_1_ID" bigint,
  CONSTRAINT "PK_TABLE_2" PRIMARY KEY ("ID" ),
  CONSTRAINT "FK_TABLE_2-TABLE_1" FOREIGN KEY ("TABLE_1_ID")
      REFERENCES "TABLE_1" ("ID") MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE ????????
)

表2中可能有很多（数百万）条目取决于表1中的条目。当我删除表1中的条目时，也应删除表2中的所有依赖条目。（没有内存不足的例外）

我看到两种可能的解决方案。

在表2中使用“ON DELETE CASCADE”。
实施一些业务逻辑以删除级联的条目

X

while (true) {
    recTable2 = table2Dao.findForTable1(table1, 100);
    if (( recTable2 != null) && (recTable2 .size() > 0)) {
       for (Table2 Table2entry : recTable2) {
            table2Dao.remove(Table2entry);
        }
    } else {
        break;
    }
}

为避免内存不足异常，一步只删除100个条目

我的问题在这里：

当我使用“ON DELETE CASCADE”的解决方案1时，如果要删除大量数据会发生什么？我是否会出现内存不足或者postgres“自动”处理此问题。
当我使用业务逻辑的解决方案2时，性能非常差！是否有更好的方法来删除大量的表条目？
您希望以哪种方式删除级联表条目？是通过业务逻辑还是通过“ON DELETE CASCADE”来完成的？

Answer 1

回答一个问题，当删除大量实体时（“通过业务逻辑做或通过”ON DELETE CASCADE“执行），我写了一些测试应用程序。

第一个应用程序存储1个TABLE_1条目和100'000个TABLE_2实体。所有TABLE_2实体都具有FOREIGN KEY“TABLE_1_ID”enty。

然后我写了两个删除所有条目的应用程序：

申请1：（业务逻辑方法）

首先在大型for循环中加载和删除所有TABLE_2实体，而不使用“ON DELETE CASCADE”关系。然后删除TABLE_1中的条目。

→此应用程序需要32秒和大约600MB的堆内存

申请2：（“ON DELETE CASCADE”方法）

使用“ON DELETE CASCADE”直接删除TABLE_1中的条目（TABLE_2中的所有条目都将被自动删除）

→此应用程序需要0.067秒和大约50MB的堆内存

所以，经过这个小小的测试后，我认为“ON DELETE CASCADE”方法要好很多倍。（快500倍，内存需要少12倍）

Answer 2

如果要在第二个表中包含数百万条记录，请更好地索引外键列。这将在删除时间方面产生巨大的差异。

SQL ON DELETE CASCADE与业务逻辑上的删除

2 个答案: