MYSQL使用連接類型「ALL」在檢查時解釋計劃

該查詢是在如下狀態，MYSQL使用連接類型「ALL」在檢查時解釋計劃

select * 
from lab this_ 
inner join visits v1_ on this_.visit_id=v1_.id

v1_.id是在查詢主鍵。

完成需要1分多鐘。

以下是計劃。

id select_type table type possible_keys key  
1  SIMPLE  v1_  ALL <null>  <null> 
1  SIMPLE  this_ ALL <null>  <null>

不知道爲什麼主鍵被選爲關鍵。還輸入是ALL。

來源

2016-11-09 Naveen Kumar

「主鍵被選爲關鍵字」 - 你在哪裏看到的？ –

如果查詢替代方案更有效，Mysql可能會在執行查詢期間忽略索引。考慮幾點：

表的大小。如果訪問表很小，那麼使用該索引沒有太多意義。
選擇性。你確實加入了兩個表格，但是沒有過濾，並且你想要兩個表格中的所有字段。這可能意味着mysql無論如何都必須返回訪問表中的大部分記錄，並且索引僅涵蓋id列。因此，mysql將被迫遍歷訪問表的大部分記錄以返回數據，因此使用該索引沒有太大的收穫。
連接另一側字段上的索引。您不會提及labs.visit_id字段是否已建立索引。如果不是，那麼再次使用訪問表的pk就會少得多。

產生的結果不依賴於所使用的指標的速度，也取決於結果集（包括記錄和字段計數），MySQL的配置，和底層系統的整體性能的大小的。儘管如此，如果您認爲mysql應該使用訪問表的pk，那麼在查詢中使用index hint以強調應該使用該索引。如果mysql受到索引提示的影響，您可以使用explain進行檢查。

來源

2016-11-09 21:56:00 Shadow

感謝您的建議。 1.Vitals表很大。 2.我只需要訪問表中的id和一個字段。 3.實驗室表中有visit_id索引。相同的表格，相同的結構，幾乎相同的行數在另一個環境中有效地工作。可能會涉及一些mysql配置？ –

2.然後只選擇那2個字段，而不是每個字段。 3.如果2個表的行數幾乎相同，那麼可能就是這個解釋。看到我的第二點關於MySQL必須從訪問表中檢索大部分記錄。你也可以說它在另一個環境中有效地工作。在其他環境中運行解釋。如果mysql在那裏使用pk，那麼嘗試一下建議的索引提示。我不可能告訴你性能差異是否與MySQL設置有關，因爲我對MySQL配置或服務器一無所知。首先嚐試索引提示。 – Shadow

MYSQL使用連接類型「ALL」在檢查時解釋計劃

回答

相關問題