Проблема с производительностью – медленный запрос к базе данных

С 2017-09-26 у меня ужасные проблемы с производительностью на моем сайте.

Загрузка отдельного поста или любой другой страницы занимает даже 20 секунд. Я проводил отладку и выяснил, что проблемы связаны с запросами к БД.

Например, этот запрос выполняется почти при каждой загрузке страницы и занимает около 36 секунд:

SELECT t.*, tt.*, tr.object_id
FROM   az2_terms AS t 
INNER JOIN az2_term_taxonomy AS tt
ON     t.term_id = tt.term_id
INNER JOIN az2_term_relationships AS tr
ON     tr.term_taxonomy_id = tt.term_taxonomy_id
WHERE  tt.taxonomy IN ('znacka', 'model')
AND    tr.object_id IN (27130, 27290, 27822, 27899, 30862, 33536, 33721, 34901, 37448, 37482, 37496, 37522, 37572, 37580, 37742, 37750, 38160, 38165)
ORDER BY t.name ASC

Когда он выполняется во второй раз, это происходит почти мгновенно. С 2017-09-26 я не вносил никаких изменений, только переключился на HTTPS, может, это и есть проблема?

Относительно редко у WP возникают проблемы с производительностью запросов на небольших или средних сайтах:

1. Запросы, которые он обычно выполняет, разумные (не идеальные, но разумные).
2. Многое, что запрашивается, активно кэшируется в процессе загрузки страницы и сохраняется с помощью кэша объектов.

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

Если изменение произошло внезапно, я бы сильно подозревал, что проблема на стороне сервера БД, и таблицы могут нуждаться в оптимизации/ремонте.

Если вы используете общий сервер с хорошим трафиком, нет смысла проводить исследования. Вам просто нужно перейти на VPS/облачный сервер.

Если это VPS/облачный сервер, такие внезапные странные задержки могут потребовать проверки вопросов безопасности. В общем, Fail2Ban достаточно, но вам нужно провести аудит безопасности, чтобы найти уязвимые плагины, вы должны протестировать различные вещи на VPS/облачном сервере, например, Высокую Доступность. Сделайте полный бэкап со всеми пользовательскими фрагментами/модификациями. Затем загрузите сайт без плагинов, без пользовательских фрагментов/модификаций, с темой по умолчанию.

Я не эксперт по базам данных, но предлагаю использовать Percona MySQL с движком InnoDB (MariaDB никак не близка к нему), отключить комментарии в WordPress и такие вещи, как пингбек, трекбек, использовать W3 Total Cache, отключить кэширование базы данных W3 Total Cache, включить кэширование MySQL и т.д. Я видел, что для WordPress тема сама по себе может быть как лучшей, так и худшей. Тема по умолчанию и StudioPress Genesis (платная) кажутся мне почти оптимальными.

Вам следует включить кэширование MySQL, что очень важно (статья Percona о кэшировании MySQL, моя статья о кэшировании MySQL) и протестировать различные настройки. Настройка базы данных из my.cnf практична после порога для колокационных серверов, едва ли хороших выделенных серверов. Если оборудование работает медленно, ничего не поможет. Я бы посоветовал прочитать этот ответ на DB StackExchange для обеих частей — аппаратной и софтовой.

В комментарии к первому ответу вы спрашиваете: “Что такое 7692832 строки?” Это 7,692,832 строк, проверенных по вашему запросу. Вероятно, гораздо больше, чем вы ожидали.

Это могут быть 43 записи, найденные с одной стороны при соединении с 180,000 записями с другой стороны или что-то подобное. При соединениях это может накапливаться быстро.

Если у вас есть запросы на данные, которые не индексированы, вам придется делать сканирование таблиц для их нахождения. Очень медленно. Убедитесь, что у вас правильно индексифицированы нужные поля для ваших запросов. Попробуйте это для помощи.