Намиране и коригиране на бавни заявки към база данни на WordPress

Бавните SQL заявки могат да повлияят отрицателно на ефективността на вашия WordPress сайт. Понякога бавните заявки са резултат от лошо оформен SQL, който трябва да бъде реализиран по малко по-различен начин. И в някои ситуации бавните заявки в началото бяха бързи - но с напредване на възрастта на сайта заявките ставаха все по-бавни и вече започнаха да изостават от разширяващата се база данни.

Независимо от това как вашият SQL се забави, нека разгледаме някои начини за намиране и коригиране на проблемни заявки в WordPress.

Намиране на бавни заявки

Намирането на източника на бавни заявки включва две стъпки:

  1. Определете кои заявки всъщност са бавни.
  2. Търсим код, който ги генерира и изпълнява.

Нека да разгледаме две приставки и едно SaaS решение, за да ни помогнат да намерим бавни заявки.

Монитор на заявки

Query Monitor е приставка, която показва различна информация за текущата страница. В допълнение към изобилните данни за WordPress вътрешните компоненти, приставката предоставя подробна статистика за следното:

  • Колко заявки са възникнали за това обаждане
  • Кои заявки на страницата отнеха най-много време
  • Кои функции отнеха най-много време на SQL заявките
  • Какви заявки идват от плъгини, теми и ядро ​​на WordPress

заявки

Query Monitor подчертава бавни заявки със страшен червен текст, който улеснява откриването на проблемен SQL:

коригиране

Бар за отстраняване на грешки

Друг чудесен инструмент за намиране на бавен SQL е добрият стар плъгин Debug Bar. Лентата за отстраняване на грешки показва информация за вътрешните елементи на WordPress, когато зареждате страница с данни като:

  1. Параметри на WP_Query
  2. Информация за обажданията (включително съответстващи правила за пренаписване)
  3. SQL заявки, генерирани от текущата страница

За да активирате третия елемент в лентата за отстраняване на грешки (проследяване на SQL), уверете се, че SAVEQUERIES е активиран на вашия сайт - това обикновено се прави във файла wp-config.php:

Предупреждение: SAVEQUERIES влияе върху ефективността на вашия сайт и най-вероятно не трябва да се използва в производствен сайт. Използвайте го само на уебсайта в процес на разработка.

Намирането на бавен SQL в лентата за отстраняване на грешки не е толкова лесно. Например приставката няма сортируеми таблици и не откроява бавни заявки. Debug Bar осигурява проследяване на функции за идентифициране на произхода на заявката.

база

Ето списък на файловете и функциите, които трябва да бъдат заредени, които ще изпълнят заявката. По принцип ще се интересувате от последния запис в списъка; тук се изпълнява най-бавната заявка и тук ще трябва да започнете търсенето си. Също така е удобно да има контекст за всяка отделна функция.

NewRelic

NewRelic е услуга, която измерва и проследява случайността на вашето уеб приложение, включително WordPress. Услугата предлага много различна информация за ефективността на вашия сайт. Много е лесно да се загубите в данните, които NewRelic предлага, от подробно изпълнение на кода до поетапни отчети за SQL заявки.

намиране

Има две основни разлики между NewRelic и приставките, споменати по-горе:

  1. NewRelic показва по-подробна информация за производителността на вашия PHP, до милисекундите, прекарани в изпълнение на всяка функция.
  2. NewRelic проследява всяка заявка към вашия сайт във фонов режим, т.е. можете да анализирате информацията по-късно, за да намерите бавен SQL. Приставките показват информация само за текущата страница.

Заслужава да се отбележи, че NewRelic има безплатен план, който ви позволява да показвате обща информация за ефективността на вашия сайт, но за да получите всички важни подробности, ще трябва да надстроите до платен план. В този план ще можете да проследявате отделни заявки и да намирате бавен SQL.

Откриване на бавни заявки с EXPLAIN

Доскоро разглеждахме инструменти за намиране на бавни заявки. Нека сега разгледаме защо тези заявки стават бавни.

Ключът MySQL EXPLAIN ще ни помогне с това. Той ще ви уведоми какво се е случило. Добавянето на EXPLAIN в началото на заявката ще покаже как MySQL изпълнява заявката. За по-сложни заявки EXPLAIN може да ви помогне да идентифицирате бавни области във вашия SQL - например бавни подзаявки или неефективни процеси.

Например, ако имате заявка като тази:

Можете да добавите EXPLAIN към него, просто като направите следното:

Ето как изглежда изходът EXPLAIN в phpMyAdmin:

Не разбирам съвсем как работят вътрешните модули на MySQL, но стартирането на EXPLAIN при заявки ми дава представа как MySQL изпълнява моята SQL заявка. Заявката използва ли индекс? Сканира ли цялата таблица? Дори и за прости заявки, EXPLAIN предоставя известна информация, която да ви помогне да разберете как работят нещата.

Можете да стартирате EXPLAIN или от командния ред на MySQL, или чрез предпочитания от вас инструмент MySQL.

Коригирайте бавни заявки

Сега, когато знаем, че заявката ни е бавна и EXPLAIN ни показа защо заявката е бавна, е време да видим как можем да отстраним тези проблеми.

Вариант 1. Заявка за промяна.

За CSS-трикове имаме заявка, която е много бавна - тази заявка е част от мета панела Потребителски полета. Ето самият SQL:

Този кодов фрагмент съдържа SQL, който ви позволява да получите списък с meta_keys от таблицата wp_postmeta. Мета-клавишите, които ни интересуват, не трябва да започват с подчертаване "_". Клауза GROUP BY означава, че всеки резултат е уникален.

След като изпълнихме тази заявка 5 пъти, ще получим следните данни:

Можем ли да напишем друга заявка, за да получим същия резултат? Трябва да изберем уникални meta_keys. Синонимът на „уникален“ е различен и както се оказва, SQL има такъв оператор!

Използвайки оператора DISTINCT, можем да направим следното:

Изпълнението на нашата модифицирана заявка няколко пъти дава следните резултати:

Това сравнение показва значително подобрение!

Вариант 2. Добавяне на индекс.

Когато изпълнявате SQL заявка срещу стандартна таблица на MySQL, MySQL сканира цялата таблица, за да определи кои редове съответстват на дадената заявка. Ако вашата маса е много голяма, сканирането ще отнеме доста време.

В този случай MySQL индексите са полезни. Индексите вземат данни от таблица и ги подреждат така, че данните да се намират най-лесно. Чрез структуриране на данни по този начин индексите помагат да се елиминират продължителните сканирания, които MySQL прави за всяка заявка.

Индексите могат да се добавят към отделни колони или към група колони. Синтаксисът е както следва:

С индекс на meta_key, оригиналната SQL заявка ще се изпълнява по следния начин:

Предупреждение относно използването на индекси: когато INSERT създаде ред или UPDATE се използва на индексирана страница, индексът се преизчислява, което е доста дълга операция. Индексите ускоряват четенето от таблица, но забавят въвеждането на данни в нея. Добре поставеният индекс може значително да ускори вашите заявки, но не бива да ги поставяте навсякъде, без да изследвате общото въздействие на индексите върху вашата база данни.

Вариант 3. Кеширане на резултатите от заявката

Знаем, че имаме бавни заявки. Вместо да ги пренаписваме, можем просто да запишем резултатите от заявката. По този начин ще ограничим честотата на изпълнение на заявката, както и ще получим "бърз отговор".

За да кешираме заявка, ни е необходим API на WordPress Transients. Преходните процеси се използват за съхраняване на резултатите от сложни операции като:

  • Заявки към външни сайтове (например извличане на най-новите публикации във Facebook)
  • Бавни блокове за обработка (напр. Търсене на дълги низове с помощта на регулярни изрази)
  • Бавни заявки към база данни

Съхраняването на резултатите от заявката в преходни процеси ще изглежда така:

Това означава, че заявката ще бъде изпълнена само веднъж на час или така. Оттук идва и едно от основните предупреждения за използването на преходно: бъдете внимателни, когато използвате преходно с данни, които често се променят.

Ако имате заявка, чиито резултати не се променят много често, използването на преходни процеси е чудесен начин да заобиколите честите обаждания към базата данни.

Избор на подход

Обмислихме три варианта и освен тях има още около 17 начина за решаване на проблема с бавни заявки. Кой подход е най-добре да се възприеме?

Когато работя с чужд код, предпочитам да се ръководя от принципа на програмистите: „Изберете най-простото решение, което може да работи“.

Първата опция (пренаписване на заявката) даде отлични резултати, но какво, ако пренаписаната заявка не винаги дава същите резултати? Можем несъзнателно да нарушим кода, като заменим заявките.

Втората опция (добавяне на индекс) не винаги е възможна, в зависимост от таблицата и колоните, използвани от заявката. В случай на основни таблици на WordPress ще трябва да помислите за възможните странични ефекти на индексирането:

  • Поддържа ли актуализацията на ядрото допълнителни индекси?
  • Добавянето на индекса ще забави ли други заявки като INSERT и UPDATE?

Третата опция (кеширане на резултати чрез преходни процеси) има минимално въздействие - не променяме оригиналната заявка и не е необходимо да променяме структурата на базата данни.

Използвам третата опция през повечето време. Във вашия случай можете да изберете различна опция, която зависи от заявката, която искате да коригирате, както и от SQL проблемите. Няма едно решение, което да работи във всички ситуации, така че опитайте различни опции.