Медленный запрос к БД

Подскажите, что тут может быть не так и как вылечить:

/system/controllers/smartwall/model.php => 11 => modelSmartwall->getData()
SELECT i.*, r.selected, u.znakomstvo, p.nickname AS `profile_nickname`, g.title AS `group_title`, u.nickname AS `user_nickname`, u.slug AS `user_slug`, u.is_deleted AS `user_is_deleted`, u.groups AS `user_groups`, u.avatar AS `user_avatar`
FROM cms_smartwall i
LEFT JOIN cms_smartwall_reactions AS r ON r.item_id = i.id AND r.user_id = 1
LEFT JOIN cms_users AS u ON u.id = i.user_id
LEFT JOIN cms_users AS p ON p.id = i.target AND i.controller = "users"
LEFT JOIN cms_groups AS g ON g.id = i.target AND i.controller = "groups"
WHERE (i.controller = 'users') AND (i.is_private = '0')
ORDER BY i.date_pub DESC
LIMIT 0, 10
Время выполнения 9.44049 секунд

/system/controllers/smartwall/model.php => 16 => modelSmartwall->getDataCount()
SELECT COUNT( i.id ) AS COUNT
FROM cms_smartwall i
LEFT JOIN cms_smartwall_reactions AS r ON r.item_id = i.id AND r.user_id = 1
WHERE (i.controller = 'users')
Время выполнения 2.56360 секунд

буду рад любому совету, сам сайт работает быстро от и до, кроме smartwall

Видимо реакций много. Во втором запросе непонятно зачем нужен джоин реакций при подсчёте количества записей. Но в любом случае надо смотреть на сами таблицы, что в них есть. Начать можно с проверки наличия индексов у этих двух таблиц. cms_smartwall cms_smartwall_reactions 

Во втором запросе это

AND r.user_id = 1

лучше вынести в WHERE для фильтрации. Но это уже вопрос к разработчику. Не у всех есть умная стена, поэтому по архитектуре, тут не подскажут. 

 Loadырь, спасибо за ответ, видимо дело и вправду в реакциях, относительно их не то чтобы много — 15 тысяч примерно, но может это и много. 

Индексы есть по id.

А есть разница MyISam или innodb, у меня первый вариант, а как понимаю сейчас мало кто его использует, mysql 5.7 если это важно.

15 тыс, не так уж и много, да и MyISam или innodb тоже такой эффект бы не дали, а то, что у вас там индексы только по id то это плохо. Нужно добавлять индексы, возможно даже составные. Какие именно сможет подсказать автор компонента. Или брать ваши запросы из стартового топика и эксплайнить их в вашей же базе данных, а потом смотреть по результатам.

 Loadырь, спасибо, смысл понял, всё верно, посмотрел индексы других таблиц cms и там буквально по всем столбцам они есть, и я когда анализировал через f12 на что уходит время во время открытия страницы, то увидел что он составляет список всех пользователей сайта и делает это два раза и делает это долго, на это и уходит время

а в одной таблице cms_smartwall_reactions есть кроме id ещё и user_id и target где по сути может быть любой пользователь, видимо на переборку и уходит врремя, а ещё и кучу полей вроде item_id, даты и д т

я запросом SHOW INDEXES FROM cms_smartwall_reactions вижу все индексы или могу не видеть составные или какие то ещё?

 Loadырь, ещё раз огромное спасибо, подтолкнули и помогли разобраться и решить проблему, добавил всего два простых индекса

CREATE INDEX user_id ON cms_smartwall_reactions (user_id);
CREATE INDEX item_id ON cms_smartwall_reactions (item_id);

и время 0.2458, а это совсем другие дела, странно почему из коробки этого не сделал автор компонента, но наверно когда создаёшь что то большое и хорошее, то без недочётов никуда.

кстати добавлю ещё мысль, может кому пригодиться из простых смертных как я, «тюнинг» Mysql не решает проблему долгих запросов или отсутствия индексов, но в целом при увеличении-изменении различных лимитов сервера базы данных, по инструкциям которые можно в яндексе нагуглить — даёт хорошей бодрости сайту, единственное аккуратнее если у вас немного оперативки на vps

я запросом SHOW INDEXES FROM cms_smartwall_reactions вижу все индексы или могу не видеть составные или какие то ещё?

Вы увидете все индексы. Только у составных будет один Key_name на несколько столбцов

странно почему из коробки этого не сделал автор компонента

Причин может быть много, но чаще всего индексы добавляют на последнем этапе разработки когда уже таблица окончательно сформиррована или  есть некая масса контента в ней, которая позволяет выявить эти доли секунды. А это на этапе разработки не всегда возможно. Да и банального «забыл» никто не отменял ))).

«тюнинг» Mysql не решает проблему долгих запросов или отсутствия индексов

«Тюнинг» сайта это целый спектр дел. И да — индексы — это не единственное, чем можно ускорить запросы в БД. Ещё можно оптимизировать сами запросы, чтобы не было лишних джоинов и задваивания запросов. Но это уже вопросы к програмистам.

Чтобы дать более внятный ответ, можете сделать EXPLAIN медленного запроса? нужно просто выполнить запрос в консоли заменив SELECT на EXPLAIN он даст результат по тому что и как делается в запросе и отсюда можно будет вам дать рекомендацию может нужно добавить правильные ключи индексов.