Оптимизатор сообщает MySQL, что будет более выгодным запустить полное сканирование таблицы в таблице сотрудников и получить оставшуюся информацию, вместо того, чтобы запускать сканирование по индексу эпизода и идентификатору роли и позже присоединиться к персоналу.

Вы можете указать подсказку о том, что сканирование таблицы очень дорогостоящее, чтобы исключить сканирование таблиц. Но есть вероятность, что оптимизатор прав, и выполнение запроса в другом направлении будет стоить вам больше.

Мне кажется, что вам нужны эти два индекса (role_ID не индексируется в вашем описании), с этой точной структурой:

CREATE INDEX production_role_ndx ON production_role(role_ID, row_index, staff_ID);

CREATE INDEX production_role_eps_ndx ON production_role_episodes(episode_index, match_index);

Вам, похоже, не нужно столько, для этого запроса (но, возможно, для других?), Эти другие:

int staff_ID (indexed)
int production_ID (indexed)

Более длинное объяснение

Ваш запрос (сокращенный):

SELECT staff_ID, name
FROM pre
JOIN pr ON (pr.row_index = pre.match_index)
JOIN sm ON (sm.staff_ID = pr.staff_ID)
WHERE pre.episode_index = {episode}    
AND pr.role_ID = {role}
ORDER BY name

Итак, что ему нужно? И откуда это удобнее начать?

Данные поступают из двух мест: индексы (получение их выполняется быстро) и таблицы (получение их происходит медленно).

Мы хотим минимизировать количество полученных кортежей, но это число является оценкой, основанной на геометрии JOIN. Затем мы хотим получить дополнительную информацию из индексов и не извлекать избыточную информацию.

Для выполнения вышеуказанного запроса требуется:

sm.staff_ID, sm name                                      for the SELECT
pr.row_index, pre.match_index, sm.staff_ID, pr.staff_ID   for the JOIN
pre.episode_index, pr.role_ID                             for the WHERE

Чтобы оптимально выполнить запрос, нам нужно как можно скорее сократить данные, поэтому нам нужно знать, больше ли индекс эпизода или мощность идентификатора роли. Скорее всего, роли несколько, а эпизодов много, а это означает, что ограничение одного эпизода из 1000 уменьшит наши данные на 1/1000, а фильтрация на роли уменьшится, может быть, на 1/20.

Поэтому мы запускаем запрос с WHERE только на pre.episode_index. И нам нужен индекс на pre, который имеет, как первое поле, episode_index. Pre - наша главная таблица.

Тогда мы присоединимся к pr. У нас также был фильтр на pr.role_ID. Как мы находим строки pr?

pr.row_index = pre.match_index
pr.role_ID = {role}

JOIN pr ON (pr.row_index = pre.match_index AND pr_role_ID = {role})

Поэтому мы хотим сначала проиндексировать pr на row_index, потому что он управляется из первой таблицы, а role_ID - второй, чтобы немедленно ограничить работу. Мы еще не получили доступ к одной из двух таблиц: мы проверили только индекс.

Если мы добавим третий столбец с идентификатором персонала в индекс pr, то данные, которые нам понадобятся в будущем, т.е. staff_ID, будут содержаться в индексе, который станет тем, что называется индексом покрытия, - и мы не будем нужна таблица pr вообще. Вы должны увидеть в EXPLAIN что-то вроде "используя буфер JOIN", что означает, что соединение происходит по частям в оптимизированных "всплесках".

Разумеется, оценка EXPLAIN будет по-прежнему основываться на количестве строк первого ГДЕ, поэтому это будет среднее число рядов эпизодов, умноженное на среднее число ролей. Это худшая оценка: вы хорошо знаете, что некоторые комбинации эпизода и роли могут фактически ничего не возвращать. Таким образом, вы не должны позволять огромной оценке беспокоиться о вас.

На данный момент у нас есть staff_main, и запрос поставляет staff_ID в качестве основного ключа, поэтому нам не нужно ничего делать: просто присоединитесь к staff_main. Для хорошей меры в select укажите, что staff_ID поступает из pr, а не staff_main. Значение такое же, и оно, вероятно, ничего не меняет, но доступ к pr.staff_ID гарантирован и прост (у нас он есть в индексе покрытия), и мы не хотим путать оптимизатор на всякий случай.