Оптимизация длинных запросов Sql

У меня есть один 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, поможет ли это вообще? Мы будем благодарны за любые чаевые! Спасибо.

Редактировать: Оптимизация длинных запросов Sql

Это индексы текущих таблиц:Оптимизация длинных запросов Sql

Что EXPLAIN говорит о вашем запросе?

Dai 20.04.2018 22:36

Дай мне взглянуть ...

The Impaler 20.04.2018 22:51

Первый внутренний выбор читает ВСЕ таблицу oc_t_mmessenger_message. Можете ли вы опубликовать, какие индексы у вас есть в настоящее время?

The Impaler 20.04.2018 22:54

Спасибо, отредактировал пост и добавил изображение индексов внизу для таблиц oc_t_messenger_message и oc_t_messenger_recipients

AlexGr 20.04.2018 23:04

Сколько строк в таблицах?

The Impaler 20.04.2018 23:12

около 1 миллиона

AlexGr 20.04.2018 23:23
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Symfony Station Communiqué - 7 июля 2023 г
Symfony Station Communiqué - 7 июля 2023 г
Это коммюнике первоначально появилось на Symfony Station .
Оживление вашего приложения Laravel: Понимание режима обслуживания
Оживление вашего приложения Laravel: Понимание режима обслуживания
Здравствуйте, разработчики! В сегодняшней статье мы рассмотрим важный аспект управления приложениями, который часто упускается из виду в суете...
Установка и настройка Nginx и PHP на Ubuntu-сервере
Установка и настройка Nginx и PHP на Ubuntu-сервере
В этот раз я сделаю руководство по установке и настройке nginx и php на Ubuntu OS.
Коллекции в Laravel более простым способом
Коллекции в Laravel более простым способом
Привет, читатели, сегодня мы узнаем о коллекциях. В Laravel коллекции - это способ манипулировать массивами и играть с массивами данных. Благодаря...
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
0
6
1 037
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

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

Следующий индекс должен ускорить внутренний выбор:

create index ix1_message on oc_t_mmessenger_message (root_id, id);

Спасибо, я добавил этот индекс, но (это может быть вопрос о дампе) разве уже нет root_id и id index? также я прочитал здесь, что «Выбранное вами сопоставление может значительно повлиять на производительность запросов в базе данных». Я использую utf8_general_ci, могу ли я изменить его на что-то более быстрое, ничего не теряя?

AlexGr 21.04.2018 14:20

Комбинированный индекс (root_id, id) отличается от двух отдельных индексов (root_id) и (id). Комбинированный решает разные проблемы.

The Impaler 21.04.2018 16:35

Спасибо, надеюсь хоть частично решит проблему.

AlexGr 21.04.2018 22:19

Возможно, вы захотите разделить свой запрос на два вместо оператора ИЛИ. нравиться:

(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.

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

Другие вопросы по теме