MySql查詢速度很慢

Question

我在我的數據庫上運行以下查詢：

SELECT e.id_dernier_fichier
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant

查詢運行正常。 如果我修改這樣的查詢：

SELECT e.codega
FROM Enfants e JOIN FichiersEnfants f
ON e.id_dernier_fichier = f.id_fichier_enfant

查詢變得非常慢！ 問題是我想在表e和f中選擇許多列，查詢最多可能需要1分鍾！ 我嘗試了不同的修改但沒有任何作用 我在e.codega上也有關於id_ *的索引。 Enfants有9000行，FichiersEnfants有20000行。 有什么建議么 ？

以下是要求的信息（抱歉沒有從頭開始顯示）：

Answer 1

性能上的差異可能是由於e.id_dernier_fichier位於用於JOIN的索引中，但e.codega不在該索引中。

如果沒有對這兩個表及其所有索引的完整定義，則無法確定。 此外，包括兩個查詢的兩個EXPLAIN計划將有所幫助。

但是現在，我可以詳細說明一些事情......

如果INDEX是CLUSTERED（這也適用於PRIMARY KEY），則數據實際上是按INDEX的順序物理存儲的。 這意味着知道你想要在INDEX中的位置x也隱含意味着你想要在表中的位置x 。

但是，如果INDEX沒有聚集，則INDEX只是為您提供查找。 有效地說INDEX中的位置x對應於表中的位置y 。

這里的重要性是訪問INDEX中未指定的字段。 這樣做意味着您必須實際轉到TABLE以獲取數據。 在CLUSTERED INDEX的情況下，你已經在那里，找到該字段的開銷非常低。 但是，如果INDEX不是聚類的，那么您必須將TABLE加入INDEX，然后找到您感興趣的字段。

注意; 具有在綜合指數(id_dernier_fichier, codega)是從具有僅在一個指數非常不同(id_dernier_fichier)和上只是一個單獨的索引(codega) 。

對於您的查詢，我認為您根本不需要更改代碼。 但您可能會從更改索引中受益。

您提到要訪問許多字段。 將所有這些字段放在復合索引中可能不是最佳解決方案。 相反，您可能想要創建一個CLUSTERED INDEX (id_dernier_fichier) 。 這意味着一旦定位了* id_dernier_fichier *，您就已經在正確的位置獲得所有其他字段。

編輯 關於MySQL和CLUSTERED INDEX的注釋

13.2.10.1。 集群和二級索引

每個InnoDB表都有一個特殊的索引，稱為聚簇索引，其中存儲了行的數據：

• 如果在表上定義PRIMARY KEY，InnoDB會將其用作聚簇索引。
• 如果沒有為表定義PRIMARY KEY，MySQL會選擇第一個只有NOT NULL列作為主鍵的UNIQUE索引，而InnoDB將它用作聚簇索引。
• 如果表沒有PRIMARY KEY或合適的UNIQUE索引，InnoDB會在包含行ID值的合成列內部生成隱藏的聚簇索引。 行按InnoDB分配給此類表中的行的ID排序。 行ID是一個6字節的字段，隨着新行的插入而單調增加。 因此，由行ID排序的行在物理上處於插入順序。