何らかの理由で、MySQLのようです インデックスSILを使用することを選択します 最初のテーブルで、両方をルックアップに使用します（WHERE sil_id = 4601038 ）およびグループ化（GROUP BY cu.Id 。
PKを使用するように指示できます テーブルの
SELECT cu.Href, COUNT(p.CatUrlId) FROM cat_urls cu
USE INDEX FOR JOIN (PRIMARY)
JOIN products p ON p.CatUrlId=cu.Id
WHERE sil_id=4601038
GROUP by cu.Id
そして、この実行計画を作成します：
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
---+-------------+-------+-------+---------------+---------+---------+------------------+------+-------------
1 | SIMPLE | cu | index | PRIMARY | PRIMARY | 4 | NULL | 1 | Using where
1 | SIMPLE | p | ref | CatUrl | CatUrl | 4 | cbs-test-1.cu.Id | 1 | Using index
列rowsで報告された値を無視します ;テーブルが空であるため、正しくありません。
Extraに注意してください 列に含まれるのはUsing whereのみになりました ただし、結合のtypeにも注意してください 列がrefから変更されました （非常に良い）index （フルインデックススキャン、あまり良くありません。）
より良い解決策は、列SIL_Idにインデックスを追加することです。 。わかっています、SIL_Id インデックスSIL(SIL_Id, AsCatId)のプレフィックスです。 理論的には、列SIL_Idの別のインデックス 完全に役に立たない。しかし、この場合の問題は解決したようです。
ALTER TABLE cat_urls
ADD INDEX (SIL_Id)
;
クエリで使用します：
SELECT cu.Href, COUNT(p.CatUrlId) FROM cat_urls cu
USE INDEX FOR JOIN (SIL_Id)
JOIN products p ON p.CatUrlId=cu.Id
WHERE sil_id=4601038
GROUP by cu.Id
クエリ実行プランが大幅に改善されました：
id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra
---+-------------+-------+------+---------------+--------+---------+------------------+------+-------------
1 | SIMPLE | cu | ref | SIL_Id | SIL_Id | 4 | const | 1 | Using where
1 | SIMPLE | p | ref | CatUrl | CatUrl | 4 | cbs-test-1.cu.Id | 1 | Using index
欠点は、（理論的には）役に立たない余分なインデックスがあることです。これはストレージスペースを占有し、行が追加、削除、またはSIL_Idを持つたびに、プロセッササイクルを消費します。 フィールドが変更されました。