Влияние составного индекса MySQL на соединения

Question

У меня есть следующий запрос SQL (БД - MySQL 5):

select
    event.full_session_id,
    DATE(min(event.date)),
    event_exe.user_id,
    COUNT(DISTINCT event_pat.user_id)
FROM
    event AS event
JOIN event_participant AS event_pat ON
    event.pat_id = event_pat.id
JOIN event_participant AS event_exe on
    event.exe_id = event_exe.id
WHERE
    event_pat.user_id <> event_exe.user_id
GROUP BY
    event.full_session_id; 

«ПОКАЗАТЬ СОЗДАТЬ СТОЛ» event »:

CREATE TABLE `event` (
  `id` int(12) NOT NULL AUTO_INCREMENT,
  `date` datetime NOT NULL,
  `session_id` varchar(64) DEFAULT NULL,
  `full_session_id` varchar(72) DEFAULT NULL,
  `pat_id` int(12) DEFAULT NULL,
  `exe_id` int(12) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `SESSION_IDX` (`full_session_id`),
  KEY `PAT_ID_IDX` (`pat_id`),
  KEY `DATE_IDX` (`date`),
  KEY `SESSLOGPATEXEC_IDX` (`full_session_id`,`date`,`pat_id`,`exe_id`)
) ENGINE=MyISAM AUTO_INCREMENT=371955 DEFAULT CHARSET=utf8

"ПОКАЗАТЬ СОЗДАТЬ СТОЛ event_participant":

CREATE TABLE `event_participant` (
  `id` int(12) NOT NULL AUTO_INCREMENT,
  `user_id` varchar(64) NOT NULL,
  `alt_user_id` varchar(64) NOT NULL,
  `username` varchar(128) NOT NULL,
  `usertype` varchar(32) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ALL_UNQ` (`user_id`,`alt_user_id`,`username`,`usertype`),
  KEY `USER_ID_IDX` (`user_id`)
) ENGINE=MyISAM AUTO_INCREMENT=5397 DEFAULT CHARSET=utf8

Кроме того, сам запрос кажется уродливым, но это устаревший код в производственной системе, поэтому мы не ожидаем его изменения (по крайней мере, на данный момент).

Проблема в том, что в таблице event (в производственной системе) имеется около 36 миллионов записей, поэтому часто происходили сбои компьютера БД из-за обработки using temporary;using filesort ( они предоставили эти EXPLAIN выходы, к сожалению, у меня их сейчас нет. Я постараюсь обновить их до этого поста позже.)

Клиент запрашивает «быстрое решение» путем добавления индексов. В настоящее время у нас есть индексы на full_session_id, pat_id, date (отдельно) на even т и user_id на event_participant. Таким образом, я думаю о создании составного индекса (pat_id, exe_id, full_session_id, date) для event - этот индекс состоит из полей в соединении (эквивалентно где?), Затем сгруппированных по, затем агрегированных (мин) частей , Это просто идея, потому что в настоящее время у нас нет такого объема данных для тестирования, поэтому мы стараемся изо всех сил в первую очередь.

Мой вопрос:

• Может ли индекс выше помочь в производительности? (Эффект довольно запутанный, потому что я нашел два действительно контрастных результата: https://dba.stackexchange.com/questions/158385/compound-index-on-inner-join-table против отдельное предложение Join в составном индексе , где последний предполагает, что составной индекс для объединений не будет работать, а первый - что он будет работать.
• Есть ли у этого пути (добавление индексов) надежды? Или мы должны забыть об этом и просто попытаться оптимизировать запрос?

Заранее спасибо за помощь:)

Обновление:

Я обновил полное описание таблиц для двух связанных таблиц.

Версия MySQL 5.1.69. Но я думаю, что нам не нужно беспокоиться о неоднозначной проблеме данных, упомянутой в комментариях, потому что кажется, что не будет двусмысленности для наших данных. В частности, для каждого full_session_id возвращается только один «event_exe.user_id» (это просто бизнес-логика в приложении)

Итак, что вы думаете о моих 2 вопросах?