Из какого индекса MySQL выиграет этот запрос?

Question

ОБНОВЛЕНИЕ: Добавлен запрос, который выполняется вторым по величине:

(может понадобиться при рассмотрении индекса ???)

SELECT m.time, m.message, m.receiver_uid AS receiver, m.sender_uid AS sender
    FROM messages AS m, users AS u
    WHERE u.uid = '$coID' 
        AND ( (m.receiver_uid = '$meID' AND m.sender_uid = '$coID') OR
              (m.receiver_uid = '$coID' AND m.sender_uid = '$meID') )
    ORDER BY m.time DESC

• $ meID - это идентификатор пользователя, который запускает wuery,
• $ coID - это идентификатор контакта.

---

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

SELECT  m2.message, m2.time, m2.sender_uid AS sender, m2.receiver_uid AS receiver, 
        m.contact, u.ufirstname
FROM (  SELECT  CASE
                WHEN sender_uid = '$me' THEN receiver_uid 
                ELSE sender_uid 
                END AS contact,
                MAX(time) AS maxtime
        FROM messages 
        WHERE sender_uid = '$me' OR receiver_uid = '$me'
        GROUP BY CASE
                 WHEN sender_uid = '$me' THEN receiver_uid 
                 ELSE sender_uid
                 END                                        ) AS m
INNER JOIN messages m2 ON m.maxtime = m2.time
AND ((m2.sender_uid = '$me' AND m2.receiver_uid = m.Contact)
OR (m2.receiver_uid = '$me' AND m2.sender_uid = m.Contact))
INNER JOIN users AS u ON m.contact = u.uid
ORDER BY time DESC

• $ me - это идентификатор пользователя, который выполняет запрос

Этот запрос (успешно) будет получать:

LAST MESSAGE from EVERY 'CONVERSATION' ordered by TIME.

Таким образом, он будет получать последнее сообщение (независимо от того, отправлено или получено сообщение) в каждом сеансе PM, а затем сортировать их по времени и получать информацию о контактах.

Пожалуйста, сообщите мнеесли бы я не объяснил это правильно.

Моя таблица MySQL выглядит следующим образом:

receiver_id | sender_id | message | time

Из какого индекса (-ов) этот запрос выиграет?

(Таблица пользователей уже имеет первичный ключ в идентификаторе, поэтому часть, в которой объединение получает имя контакта, должна быть эффективной)

ОБЪЯСНЕНИЕ ВЫХОДОВ:

БОЛЬШОЙ запрос:

id  select_type     table   type    possible_keys   key     key_len     ref     rows    Extra
1   PRIMARY     <derived2>  ALL     NULL    NULL    NULL    NULL    4   Using temporary; Using filesort
1   PRIMARY     m2  ALL     NULL    NULL    NULL    NULL    42  Using where
1   PRIMARY     u   eq_ref  PRIMARY     PRIMARY     4   m.contact   1   Using where
2   DERIVED     messages    ALL     NULL    NULL    NULL    NULL    42  Using where; Using temporary; Using filesort

Запрос в части обновления:

id  select_type     table   type    possible_keys   key     key_len     ref     rows    Extra
1   SIMPLE  u   const   PRIMARY     PRIMARY     4   const   1   Using index; Using filesort
1   SIMPLE  m   ALL     NULL    NULL    NULL    NULL    42  Using where

Answer 1

По следам и ошибкам я обнаружил, что индексирование времени уменьшает время загрузки.Так что, вероятно, это будет ответом на мой вопрос.

Answer 2

По мере роста вашей таблицы сообщений этот запрос будет становиться все медленнее и медленнее.В зависимости от количества разговоров, в которые входит пользователь, вы начнете видеть экспоненциально убывающую производительность.Хотя отдельный индекс для messages.time, messages.sender_uid и messages.receiver_uid пока поможет, ни один индекс не поможет вам в долгосрочной перспективе, если вы не урежете свою таблицу сообщений.Особенно, когда у вас более нескольких сотен тысяч сообщений.

Я бы предложил сохранить тип типа ассоциации, который связывает пользователя с беседой и его идентификатором последнего сообщения.Нечто похожее:

user_id |Идентификатор разговора |message_id

Затем вы просматриваете эту таблицу вместо выполнения сложного и дорогого запроса.Это значительно уменьшает количество сканирований, которые вам нужно выполнить в таблице сообщений.Хотя это немного увеличивает сложность, производительность не снизится так сильно, как ваш запрос выше.