在MySQL中僅對一列建立索引的性能

Question

在僅包含實例化查詢的主鍵的臨時表上創建索引有什么好處？

我想從特定表以及具有外鍵引用的其他相關表中刪除一些數據。 為了提高性能，我將最初的選擇具體化到一個臨時表中，然后將其加入以進行后續刪除。

臨時表僅包含一列-子查詢的主鍵。 在臨時表的id列上創建索引是否對性能有好處？ 在測試中，我看到了大約2％的改進（然后被索引創建的開銷所抵消），但是也許可供我測試的數據集不夠大。

CREATE TEMPORARY TABLE ids AS (SELECT id FROM tableA WHERE xxx);
DELETE tableB FROM tableB INNER JOIN ids ON tableB.a_id = ids.id;
DELETE tableC FROM tableC INNER JOIN ids ON tableC.a_id = ids.id;
...
DELETE tableA FROM tableA INNER JOIN ids ON tableA.id = ids.id;

由於ids臨時表中的所有行都將用於刪除tableB中的行（a_id已建立索引），因此在ids臨時表上創建主鍵/索引是否對性能有好處？ 是否有更好的更好的，完全不同的方法來解決此問題？

Answer 1

這完全取決於您運行的查詢類型。 如果只運行需要讀取或返回整個表或整個表的重要子集的查詢，則添加索引只會導致寫入性能下降（它總是如此）。 如果您經常執行可使用此類索引來減少表中磁盤頁面I / O數量的查詢（因為您僅查找一行，或者只查找很小的行數），則添加索引將顯着提高了這些查詢的性能。

Answer 2

實際上，這是主鍵索引可能對性能造成危險的一種情況。

您擁有的查詢本質上具有兩個邏輯執行路徑。 一種是讀取“其他”表並查找id中的值。 第二種是讀取id表並在“ other”表中查找值。 假定id比另一個表小得多，后一種執行計划是最好的。

主鍵索引的問題在於，通過真正使第一個選項看起來合理，可能會混淆優化器。 如果您信任優化器，那么擁有索引是沒有問題的。 但這確實增加了混淆的可能性。

現在讓事情進一步混亂，在某些情況下擁有索引將非常有益。 當ids表相對於其他表較大時，就會發生這種情況-而且它們也很大。 在這種情況下，您要按“主鍵”順序對“其他”表進行刪除。 因此，按順序讀取該表並查找ID是有意義的。 僅當大多數頁面上至少有兩個要刪除的記錄時，情況才會如此。