У меня есть сценарий, в котором я, хотя и оптимизировал запрос, но не понимаю, на каком основании оптимизатор запросов выбирает использование определенного индекса.Я выполняю следующий запрос.
<code> SELECT r.review_id FROM game_reviews r
INNER JOIN game_subchannel gs ON r.game_id = gs.game_id
WHERE gs.subchannel_id=4
Мой стол game_subchannel - это таблица отношений, которая отображает game_id на subchannel_id.Изначально у меня был индекс с несколькими столбцами game_subchannel_idx
для столбцов game_id и subchannel_id.Индексное количество элементов для обоих этих столбцов составляет 4547, то есть количество строк в таблице.Когда я сделал EXPLAIN
для запроса только с game_subchannel_idx
, в столбце Extra было бы показано 3411 строк и using where, using index
, что, как я прочитал, означает, что он выполняет полное сканирование индекса и не использует индекскак мне в идеале хотелось бы.
Мой вопрос здесь для первого случая заключается в том, почему MySQL не использует game_subchannel_idx
для выделения строк на основе заданного условия?, т.е. зачем смотреть 3411 строк?Насколько я понимаю, у него должен быть узкий ряд строк, на которые нужно смотреть.И, следовательно, почему он выполняет полное сканирование индекса?
Позже я создал новый индекс с одним столбцом subchannel_idx
только для столбца subchannel_id.Количество элементов индекса здесь равно 32. Теперь, когда я делаю EXPLAIN
для этого запроса, он отображает как индекс в столбце «возможные ключи», так и subchannel_idx
в столбце ключей.И 645 в столбце строк.И столбец Extra
пуст.Итак, по-видимому, я теперь оптимизировал запрос, то есть 3411 против 645. Но я не понимаю, процесс, есть много путаницы.Мой вопрос ко второму случаю: почему MySQL предпочитает subchannel_idx
над game_subchannel_idx
, хотя у первого очень низкая мощность?Я прочитал, что MySQL обычно предпочитает индексы с большей мощностью.