當從Oracle中的大表中刪除時 - 讓我們稱之爲表X--禁用沒有ON DELETE CASCADE的表X的FK是否合理？我並不是指在鏈接到表X的其他表上禁用FK，而只是禁用表X上的FK來提高DELETE語句的性能。Oracle性能 - 禁用FK以使DELETE語句更快地工作？
我使表X上的索引不可用，但DELETE仍需要一段時間。
我認爲那些FK對DELETE語句的性能無關緊要，因爲我們只是刪除而不是插入或更新，所以FK不需要檢查。你怎麼看？
最終，我並沒有在存檔過程開始之前禁用這些FK，並在過程結束時啓用它們。但是，爲了提高DELETE語句的性能，我們必須在歸檔過程開始之前刪除索引，並在歸檔過程完成後重新創建它們。我們也更經常地承諾。
這似乎是一個非常糟糕的主意。不管你做什麼，你都會有一段時間，在你的數據庫上不執行參照完整性。然後你去把FKs放回原處，哎呀，有人插入了一個無效行。
此外，ALTER TABLE是一個DDL語句，因此執行它將提交到那一點的任何工作。如果事務中其他地方發生錯誤，您將失去回滾能力。
你可以通過解釋計劃來看看爲什麼你的DELETE聲明花了這麼長時間嗎？
我正在討論一個數據庫歸檔過程，它會在所有用戶被鎖定的情況下運行，所以不用擔心有人在FK被禁用時插入無效行。當沒有任何提交時，ALTER TABLE也會在歸檔作業的開始處發生。解釋計劃顯示了索引的用法，一切看起來都很正常。我認爲這裏主要的問題是表格的體積和索引的數量（我只能使它們中的一部分不可用） – 2011-05-25 16:00:57
我認爲kurosch提供了一個很好的觀點：當你指向你的表格時，FKs仍然需要驗證做刪除，以確保你沒有刪除一個子記錄。也許這就是問題所在？ – eaolson 2011-05-25 23:20:07
只有存在外鍵（具有相應的索引）纔有可能導致刪除使用錯誤的索引。你能否以一種使用正確索引的方式編寫DELETE，比如說提示或修改where子句？ – MJB 2011-05-13 20:18:01
很可能是FK指向/表/ X導致任何延遲，或者可能是表中的數據量。 – kurosch 2011-05-13 20:55:30