什麼是MySQL中的「point-in-select」？

我被給了這個查詢來更新報告，並且在我的計算機上運行需要很長時間。什麼是MySQL中的「point-in-select」？

select 
c.category_type, t.categoryid, t.date, t.clicks 
from transactions t 
join category c 
    on c.category_id = t.categoryid

我問DBA是否有與查詢的任何問題，而DBA優化以這種方式查詢：

select 
    (select category_type 
    from category c where c.category_id = t.categoryid) category_type, 
    categoryid, 
    date, clicks 
from transactions t

他所描述的第一子查詢的「點式選」。我從來沒有聽說過這個。有人可以解釋這個概念嗎？

來源

2016-07-25 Zachary Chetchavat

而且第二個查詢有更好的表現嗎？我認爲他們應該非常相似。此外，我從來沒有聽說過「點選」，Google也沒有提到任何事情。 –

你有提供兩種'EXPLAIN'的機會嗎？第二個查詢實際上看起來更糟。 – zerkms

這是[相關子查詢]（https://en.wikipedia.org/wiki/Correlated_subquery）。請注意，他的短語沒有出現在維基鏈接中，我從來沒有聽說過它。令我驚訝的是，這使您在RDBMS的現代版本上顯着提高了性能。 –

我要指出，這兩個查詢是不一樣的，除非符合下列條件：

transactions.categoryid總是出現在category。
category沒有重複的值category_id。

實際上，這些都是真實的（在大多數數據庫中）。第一個查詢應該是使用left join版本更接近等價：

select c.category_type, t.categoryid, t.date, t.clicks 
from transactions t left join 
    category c 
    on c.category_id = t.categoryid;

還是不完全一樣，但更多的類似。

最後，這兩個版本都應該使用category(category_id)上的索引，我期望MySQL中的性能非常類似。

來源

2016-07-25 21:19:47

您的DBA的查詢與其他人指出的查詢和afaik非標準SQL不一樣。僅僅因爲它的簡單性，你就更加可取。

重新編寫性能查詢通常不是有利的。它有時可以提供幫助，但DBMS應該等效地執行邏輯上等效的查詢。不這樣做是查詢計劃者中的一個缺陷。

性能問題通常是物理設計的一個功能。在你的情況下，我會尋找category和transactions表中包含categoryid作爲第一列的索引。如果兩者都不存在，那麼您的加入是O（mn），因爲必須針對每個事務行掃描category表。

不是MySQL用戶，我只能建議您獲取查詢計劃器輸出並查找索引機會。

來源

2016-07-25 23:59:47

什麼是MySQL中的「point-in-select」？

回答

相關問題