為什么附加子查詢的最小ID會使結果快10倍？

Question

當用於限制id范圍的附加子查詢給出的結果比WHERE中相同查詢的結果快10倍時，會遇到奇怪的情況。

此查詢大約需要10秒：

SELECT COUNT(DISTINCT i.id) AS count FROM
      items i
      INNER JOIN items_keywords ik ON ik.article_id = i.id AND ik.deleted = 0
      INNER JOIN category_keywords catk ON catk.keyword_id = ik.keyword_id
      INNER JOIN category cat ON cat.id = catk.category_id AND cat.customer_id = 968
      WHERE 
         i.deleted = 0 
         AND i.edited = 1 
         AND i.created >= '2018-12-18' 
         AND i.created <= '2018-12-20 23:59:59'

說明：

如果我添加其他where子句來設置最小ID，則最多需要1秒鍾的時間：

AND i.id > (SELECT MIN(id) FROM items WHERE created >= '2018-12-01')

說明：

使用子查詢設置i.id范圍（在主查詢中刪除i.created，並且沒有最小id子句）對其進行測試，它花費了10s的時間，並且解釋與第一個查詢相同，除了子查詢行和主查詢中沒有創建的索引。

AND i.id IN (SELECT id FROM items WHERE created >= '2018-12-18' AND created <= '2018-12-20 23:59:59') #subquery takes 0,047s

因此，我應該更改索引中的某些內容還是將最小ID子查詢添加到我的所有查詢中，因為這會大大提高？ 等待任何建議。

某些規格：Mysql：5.6.4
項目表：2200萬行
items_keywords：1.2億行
category_keywords：70M行

這是我的第一個問題，所以不要怪我，而要教我。

添加在：
這是這些表的SHOW CREATE TABLE

Answer 1

快10倍-聽起來就像是在buffer_pool中緩存的數據與沒有緩存的數據之間的差異。 您是否將每個查詢兩次？

請為每個表提供SHOW CREATE TABLE ； 可能會發生很多微妙的事情。

該索引可能會誘使它首先使用：

INDEX(deleted, edited,  -- in either order
      created,          -- after those others
      id)               -- last

該索引正在“覆蓋”，從而提供了額外的推動力。

當前，優化器決定從cat.customer_id = 968開始。

如果category_keywords是多方面的：許多映射表，看到這幾個性能提示。

IN ( SELECT ... )可能會過慢。 EXISTS ( SELECT ... )可能更快。

如果要將內容移動到子查詢中，請移動所有i. 測試到它。 這樣，它本質上將類似於EXISTS ，並且可以使用PRIMARY KEY(id)作為完美索引。 （不需要額外的索引。）