У меня есть один sql-запрос, который отключает весь мой сервер, когда на сайт вошло много людей.
я потратил весь день, пытаясь выяснить, как это исправить с помощью руководств по индексации, но я все еще не могу понять, как я могу исправить этот запрос или могу ли я вообще
Это запрос:
SELECT t.id,
t.title,
t.s_secret,
t.content,
t.senton,
t.hidden,
t.reported,
t.root_id,
t.sender_id,
t.s_contact_name,
t.s_contact_email,
t.item_id,
t.status_id,
t.event_id,
l.id AS last_id,
l.title AS last_title,
l.s_secret AS last_s_secret,
l.content AS last_content,
l.senton AS last_sentOn,
l.hidden AS last_hidden,
l.reported AS last_reported,
l.root_id AS last_root_id,
l.sender_id AS last_sender_id,
l.s_contact_name AS last_s_contact_name,
l.s_contact_email AS last_s_contact_email,
l.item_id AS last_item_id,
l.status_id AS last_status_id,
l.event_id AS last_event_id,
last.count AS t_count
FROM oc_t_mmessenger_recipients r
JOIN oc_t_mmessenger_message l
ON l.id = r.message_id
JOIN (SELECT Max(im.id) AS max,
Count(1) AS count
FROM oc_t_mmessenger_message im
GROUP BY root_id) last
ON r.message_id = last.max
JOIN oc_t_mmessenger_message t
ON t.id = l.root_id
JOIN oc_t_mmessenger_message_labels ml
ON ( ml.fk_i_message_id = t.id
AND ml.fk_i_label_id = 1
AND ml.fk_i_user_id = 2569 )
WHERE ( r.recipient_id = 2469
OR l.sender_id = 2469 )
ORDER BY last.max DESC
LIMIT 0, 10
Если я создал индекс через phpmyadmin для таких таблиц, как recipient_id и sender_id, поможет ли это вообще? Мы будем благодарны за любые чаевые! Спасибо.
Дай мне взглянуть ...
Первый внутренний выбор читает ВСЕ таблицу oc_t_mmessenger_message. Можете ли вы опубликовать, какие индексы у вас есть в настоящее время?
Спасибо, отредактировал пост и добавил изображение индексов внизу для таблиц oc_t_messenger_message и oc_t_messenger_recipients
Сколько строк в таблицах?
около 1 миллиона






Хорошо, у вас есть несколько индексов, о которых я думал, так что вы не так уж и далеко. Теперь этот внутренний выбор убивает производительность.
Следующий индекс должен ускорить внутренний выбор:
create index ix1_message on oc_t_mmessenger_message (root_id, id);
Спасибо, я добавил этот индекс, но (это может быть вопрос о дампе) разве уже нет root_id и id index? также я прочитал здесь, что «Выбранное вами сопоставление может значительно повлиять на производительность запросов в базе данных». Я использую utf8_general_ci, могу ли я изменить его на что-то более быстрое, ничего не теряя?
Комбинированный индекс (root_id, id) отличается от двух отдельных индексов (root_id) и (id). Комбинированный решает разные проблемы.
Спасибо, надеюсь хоть частично решит проблему.
Возможно, вы захотите разделить свой запрос на два вместо оператора ИЛИ. нравиться:
(SELECT
# everything from your query
WHERE r.recipient_id = 2469)
UNION
(SELECT
# everything from your query, again
WHERE l.sender_id = 2469)
Таким образом, вы сможете использовать индексы recipient_id и sender_id.
Но, как говорят другие, самая большая проблема, вероятно, заключается во внутреннем выборе.
Что
EXPLAINговорит о вашем запросе?