Как да използваме EXPLAIN в MySQL за разбиране и ускоряване на заявките

Начало » Питон » Как да използваме EXPLAIN в MySQL за разбиране и ускоряване на заявките

Ако работите с MySQL достатъчно дълго, рано или късно ще срещнете бавна заявка, която ще ви съсипе деня. Може би отчет, който никога не завършва, крайна точка на API, която изтича при натоварване, или табло, което внезапно се зарежда за 20 секунди. Когато това се случи, първият истински инструмент за отстраняване на грешки, към който трябва да посегнете, е EXPLAIN семейство от команди.

MySQL EXPLAIN и EXPLAIN ANALYZE показват как оптимизаторът планира и реално изпълнява заявка. Използвани правилно, те разкриват кои таблици се сканират, кои индекси се използват (или игнорират), как се извършват съединения, колко реда се проверяват и къде всъщност се изразходва време. В това ръководство ще разгледаме, на разбираем език, как да ги използваме, как да четем техния резултат и как да превърнем тази информация в конкретни подобрения в производителността.

Какво прави EXPLAIN в MySQL (и кога да го използваме)

В MySQL, EXPLAIN Ключовата дума е диагностичен инструмент, който показва планираната стратегия за изпълнение на даден оператор, вместо да го изпълнява нормално. Вие поставяте EXPLAIN пред вашата заявка, а MySQL отговаря с малка таблица, описваща как възнамерява да получи заявените редове.

Можете да използвате EXPLAIN с SELECT, INSERT, UPDATE, DELETE намлява REPLACE изрази, не само SELECT. Например:

Пример:

Пример за заявка: EXPLAIN SELECT * FROM employees WHERE last_name = 'Puppo' AND first_name = 'Kendra';

Вместо да връща данни за служителите, MySQL връща обяснение ред по ред за това как би изпълнил този оператор. Ще видите коя таблица е прочетена, кой индекс е избран, колко реда MySQL очаква да провери и допълнителни бележки, като например дали е необходима временна таблица или файлово сортиране.

Използвайте EXPLAIN, когато подозирате, че дадена заявка е по-бавна, отколкото би трябвало, или когато проектирате индекси и искате да проверите дали MySQL действително ще ги използва. Също така е изключително полезно, когато наследявате сложен SQL код с множество подзаявки и съединения и трябва да направите обратно инженерство на това, което прави оптимизаторът.

Вариации на EXPLAIN: EXTENDED, PARTITIONS, ANALYZE и формати

Основният EXPLAIN е само отправната точка; MySQL предлага няколко разширения и изходни формати, които дават по-задълбочена представа. Разбирането на тези опции ви помага да изберете правилното ниво на детайлност за всяка ситуация.

EXPLAIN EXTENDED добавя повече информация за оптимизатора, особено filtered колона и пренаписан текст на заявката. След бягане EXPLAIN EXTENDED ... можете да изпълните SHOW WARNINGS; за да видите как оптимизаторът е пренаписал вашата заявка вътрешно, което е много удобно за разбиране на решенията за оптимизация.

EXPLAIN PARTITIONS показва кои дялове от разделена таблица ще бъдат достъпни от заявката. - partitions Колоната изброява съответните дялове, което ви помага да проверите дали действително се извършва „орязване“ на дялове и дали не попадате върху всеки дял случайно.

Изходният формат също е гъвкав: можете да получите табличен, разделен с табулации, вертикален или JSON изход в CLI и визуални планове в инструменти като MySQL Workbench. JSON изходът е особено полезен за автоматизация и по-задълбочен анализ, защото включва оценки на разходите и вложена структура на плана, но имайте предвид, че обикновените EXPLAIN ANALYZE В MySQL в момента не се поддържа суров JSON изход.

Визуални инструменти като MySQL Workbench могат да представят EXPLAIN като графично дърво, което често е по-лесно за разбиране при сложни съединения и подзаявки. Външни инструменти като Percona Toolkit, EverSQL или Releem могат да консумират изхода на EXPLAIN или да забавят лог файловете на заявките и да ви помогнат да приоритизирате кои оператори да оптимизирате първо.

Разбиране на колоните EXPLAIN (табличен формат)

Когато изпълнявате класически EXPLAIN без JSON формат, MySQL връща по един ред за всяка таблица или подзаявка, включени във вашия оператор. Редът на тези редове е от значение: той показва последователността, в която се осъществява достъп до таблиците по време на изпълнение.

Това са ключовите колони, които ще видите, и какво ви казват те:

• id: Последователен идентификатор за всяка част от заявката. Един прост SELECT обикновено има id = 1Множеството идентификатори показват подзаявки, производни таблици или UNION части. По-високите числа обикновено се изпълняват преди по-ниските, което ви дава представа за реда на изпълнение.
• select_type: Описва ролята на този SELECT в рамките на цялостната заявка, със стойности като SIMPLE (без подзаявки или UNIONS), PRIMARY (най-външният SELECT в сложна заявка), UNION, UNION RESULT, DERIVED (подзаявка в FROM) или типове, свързани с пълен текст. Това ви позволява да видите с един поглед дали имате работа с вложени заявки, обединения или производни таблици.
• table: Показва към коя таблица или вътрешен резултат се отнася този ред. Може да бъде истинско име на таблица или псевдоиме, като например <unionM,N> за вътрешен резултат на СЪЮЗА, <derivedN> за производна таблица или подобни маркери за материализирани подзаявки.
• partitions: Когато използвате разделени таблици заедно с EXPLAIN PARTITIONS, това изброява дяловете, които съдържат редове, съответстващи на условията на заявката. Ако видите много изброени дялове, е възможно да не се възползвате от подрязването на дялове.
• type: Често наричан тип съединение или достъп, това е един от най-важните показатели за производителност. Той описва как MySQL осъществява достъп до редове: стойностите варират от много ефективни (като const, eq_ref, ref) до по-малко ефективни (range) до лошо (index, ALL пълно сканиране на таблицата). Специални типове като index_merge, unique_subquery, и index_subquery посочете конкретни оптимизации.
• possible_keys: Изброява индекси, които MySQL счита, че биха могли да се използват за тази част от заявката. Ако това е NULL, това означава, че MySQL не вижда полезен индекс, което е силен сигнал, че може да се наложи да създадете такъв въз основа на вашите условия WHERE или JOIN.
• key: Показва действителния индекс, избран от оптимизатора за този достъп. Ако е NULL докато possible_keys изброява кандидати, оптимизаторът е решил, че използването на индекс не си струва, често поради ниска селективност или малък размер на таблицата.
• key_len: Показва броя на използваните байтове от индекса. За съставни индекси това показва колко водещи колони са ефективно заети. Това е от решаващо значение за разбирането дали вашият многоколонен индекс се използва изцяло или само частично.
• ref: Показва какво се сравнява с индексните колони, изброени в key: може да сочи към друга колона от таблицата (за съединения) или към константа (за прости филтри).
• rows: Приблизителна оценка за броя редове, които MySQL очаква да разгледа за тази стъпка. Тя е приблизителна, базирана на статистика, но много полезна за оценка на това колко скъпа ще бъде заявката и дали индексът намалява ефективно пространството за търсене.
• filtered: Предлага се с EXPLAIN EXTENDED, този процент представлява колко от изследваните редове се очаква да отговарят на условията на тази таблица. Ниските проценти, комбинирани с високи rows често крещят за по-добро индексиране или по-селективни условия.
• Extra: Поле в свободна форма, съдържащо допълнителни бележки, които не се побират другаде, като например Using index, Using where, Using temporary, Using filesort, подсказки за пълен текст и други, всички от които съдържат важни насоки за производителност.

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

Как EXPLAIN дефинира типовете достъп ( type колона)

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

На високо ниво, типовете достъп варират от „отличен“ до „ужасен“ по отношение на производителността. Въпреки че точният списък е дълъг, важните включват:

• const / system: MySQL може да разреши таблицата до най-много един ред чрез първичен ключ или уникален индекс с константна стойност. Това е изключително ефективно.
• eq_ref: За всеки ред от предишната таблица, MySQL прочита точно един съответстващ ред от тази таблица, обикновено поради уникална или първична ключова препратка в съединение.
• ref: MySQL осъществява достъп до редове чрез неуникален индекс, съответстващ на константа или колона; може да съвпадат няколко реда. Като цяло все още е добре.
• range: MySQL използва индекс за извличане на редове в даден диапазон от стойности (например, BETWEEN, >=или съвпадение на префикс с LIKE 'abc%'). Това често е приемливо, особено за диапазони от дати или числа.
• index: MySQL сканира целия индекс, вместо пълните данни от таблицата. По-добре от пълно сканиране на таблица, но все пак често е твърде скъпо при големи индекси.
• ALL: Пълно сканиране на таблица. MySQL чете всеки ред, за да намери съвпадения. При малки таблици това може да е добре, но при големи таблици обикновено трябва да обмислите индексиране или пренаписване на заявки, за да го избегнете.
• index_merge: Показва, че MySQL комбинира резултати от множество индекси в една и съща таблица. Звучи добре, но на практика често се представя по-зле от добър единичен съставен индекс.
• unique_subquery / index_subquery: Специални типове достъп, използвани за оптимизиране на определени IN (SELECT ...) подзаявки чрез търсене по уникалност или неуникален индекс, замествайки по-малко ефективните модели на търсене.

Когато преглеждате изхода на EXPLAIN, обикновено искате типовете достъп да са възможно най-близо до const / eq_ref / ref колкото е възможно и избягвайте ALL на големи маси. Ако виждаш ALL с високо rows оценка, почти винаги е кандидат за по-добро индексиране.

Key, possible_keys и key_len: наистина ли вашите индекси помагат?

Индексите често са най-мощният начин за ускоряване на заявките, а EXPLAIN ви помага да разберете как точно се използват. Три колони са особено важни за диагностиката на индекса: possible_keys, key, и key_len.

possible_keys изброява всички индекси, които MySQL смята, че биха могли да бъдат релевантни за тази таблица, въз основа на условията WHERE и JOIN. Ако това е NULL За таблица, която участва в интензивен филтър или съединение, това е силен намек, че трябва да обмислите добавянето на индекс, който обхваща съответните колони.

key ви казва кой индекс MySQL всъщност е избрал от кандидатите. If key is NULL докато има записи в possible_keys, оптимизаторът е решил, че пълното сканиране е по-евтино, което обикновено показва лоша селективност на индекса, остаряла статистика или модел на заявка, който не може да се възползва от наличния дизайн на индекса.

key_len показва колко байта от избрания индекс са използвани. За съставни индекси това ви позволява да потвърдите колко от индексираните колони допринасят за търсенето. Ако сте изградили индекс върху (last_name, first_name) намлява key_len покрива само дължината за last_name, знаете, че заявките не се възползват максимално от съставния индекс.

- ref колоната допълва това, като ви казва какво MySQL сравнява с индекса, независимо дали е константа (като 'Puppo') или колона от обединена таблица. Ако отстранявате грешки в съединение, виждайки правилната колона за съединение в ref заедно с добро type стойност като например eq_ref е знак, че вашето съединение е добре индексирано.

Редове, филтрирани и допълнителни: откриване на скрити неефективности

- rows намлява filtered колоните дават приблизителна представа за обема на работата, докато Extra подчертава специални операции, които често обясняват проблеми с производителността. Тези три винаги трябва да се разглеждат заедно.

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

filtered (достъпно чрез EXPLAIN EXTENDED) дава приблизителния процент на проверените редове, които ще отговарят на условията за тази таблица. Висок rows с много ниско filtered Процентът обикновено сочи към липсващи или неоптимални индекси или лошо селективни предикати.

- Extra колоната обобщава допълнителни бележки за изпълнението, които не се вписват никъде другаде. Някои от най-важните стойности, с които може да се сблъскате, включват:

• Using where: Прилага се условие WHERE за филтриране на редове за тази таблица.
• Using index: MySQL може да обслужва всички необходими колони само от индекса, без да докосва данните от таблицата, което е известно като покриващ индекс и като цяло е много ефективно.
• Using temporary: MySQL създава вътрешна временна таблица за съхранение на междинни резултати, например за сложна обработка на GROUP BY или подзаявки. При големи масиви от данни това може сериозно да повлияе на производителността.
• Using filesort: MySQL извършва отделна стъпка за сортиране, често за ORDER BY или GROUP BY, която може да се извърши в паметта или на диска и обикновено е по-скъпа от използването на подреждане, базирано на индекси.
• Бележки, свързани с пълния текст: Когато се използват FULLTEXT индекси, EXPLAIN може да разкрие дали търсенето на пълен текст се комбинира правилно със съединения или други филтри.

Обърнете специално внимание на Using temporary намлява Using filesort in Extra когато заявките са бавни, тъй като и двете могат да показват тежка работа по сортиране или групиране, която може да бъде прехвърлена към по-добри индекси или преструктурирани заявки.

ОБЯСНЕТЕ АНАЛИЗИРАЙТЕ: виждане на реалните разходи за изпълнение

Започвайки с MySQL 8.0.18, получавате още по-мощен инструмент: EXPLAIN ANALYZE, който всъщност изпълнява заявката и прикачва статистика по време на изпълнение към плана. Това преодолява разликата между теоретичните оценки на разходите и реалните резултати.

За разлика от обикновения EXPLAIN, който само предсказва, EXPLAIN ANALYZE изпълнява оператора и измерва колко време отнема всеки итератор (стъпка) в плана, колко реда връща и колко цикъла изпълнява. Синтаксисът е ясен:

Стартирайте: EXPLAIN ANALYZE SELECT * FROM table_name WHERE condition;

Когато изпълнявате EXPLAIN ANALYZE, MySQL използва FORMAT=tree автоматично и извежда дървовиден план, който комбинира прогнозни и действителни показатели. За всеки възел можете да видите:

• Очаквана цена на изпълнението: Моделът на оптимизатора за това колко скъпа трябва да бъде тази стъпка.
• Очаквани редове: Колко реда се очакваше да бъдат върнати от този итератор.
• Действително време до първия ред: Колко време отне, преди да бъде произведен първият ред.
• Действително време, прекарано на цикъл: Средно време в милисекунди за изпълнение на итератора, включително неговите деца, но не и родителя, в цикли.
• Действителни редове и бримки: Колко реда са наистина върнати и колко пъти е изпълнен итераторът.

Можете да използвате EXPLAIN ANALYZE с SELECT, многотаблични UPDATE, DELETE и TABLE оператори. Това е особено полезно, когато нормалният EXPLAIN предлага едно нещо, но заявката все още се държи различно в продукцията, защото сега можете да сравните прогнозния спрямо действителния брой редове и разходи.

Големите несъответствия между оценките и действителните стойности разкриват къде статистиката на оптимизатора е неправилна или къде сложни предикати (включително функции, UDF или съхранени рутини) правят прогнозирането на разходите неточно. Тези места са основни цели за промени в схемите, нови индекси или пренаписване на заявки.

Класическо ОБЯСНЕНИЕ срещу ОБЯСНЕНИЕ АНАЛИЗ: силни и слаби страни

Въпреки че EXPLAIN и EXPLAIN ANALYZE са изключително полезни, важно е да се разберат техните недостатъци, за да не се прекалява с интерпретацията на резултата.

Обикновеното EXPLAIN е по същество приближение на това, което оптимизаторът смята, че ще се случи. Някои от статистическите му данни са груби оценки, а определени вътрешни оптимизации изобщо не се показват в резултата. Например, не показва как тригерите, съхранените функции или потребителски дефинираните функции ще повлияят на процесорното време. Също така не показва какво се случва в съхранените процедури.

Някои етикети в изхода са опростено описание на това, което всъщност се случва. Например, type Колоната се нарича тип съединение, въпреки че всъщност представлява типа достъп. Extra стойност Using temporary не прави разлика между временни таблици в паметта и временни таблици на диска, и Using filesort обхваща както видовете, базирани на памет, така и тези, базирани на диск, под един и същ етикет.

EXPLAINN ANALYZE решава някои от тези проблеми, като показва реално време и брой редове, но има и компромиси. Трябва да се изпълни заявката, което може да е скъпо или дори опасно в производствения процес, ако заявката е ресурсоемка или променя данни. Също така, суровият JSON изход в момента не е достъпен директно за EXPLAIN ANALYZE, така че ще работите предимно с дървовидния формат в CLI или клиентските инструменти.

Правилният подход е да използвате EXPLAIN за бърз и минималистичен анализ на плана, а EXPLAIN ANALYZE за по-задълбочени проучвания, където можете да си позволите действително да изпълните заявката.

Използване на EXPLAIN и EXPLAIN ANALYZE за оптимизиране на реални заявки

Четенето на EXPLAIN е полезно само ако води до по-добри заявки; ключът е да се преведе видяното в специфични промени в индекса и SQL. Нека разгледаме някои често срещани сценарии за оптимизация, с които можете да се справите директно с помощта на EXPLAIN.

Представете си просто запитване към employees таблица без съответни индекси:

Пример за филтър: EXPLAIN SELECT * FROM employees WHERE last_name = 'Puppo' AND first_name = 'Kendra';

Без индекси, EXPLAIN вероятно ще покаже type = ALL и много голяма стойност в rows (например, около 299 000 реда), което показва пълно сканиране на таблицата. Това е ясен сигнал, че ви е необходим индекс, който поддържа и двете условия.

Един наивен подход е да се създадат два отделни индекса, единият на last_name и един на first_name, но това все още не прави комбинираното търсене ефективно. MySQL може бързо да намери всички с last_name = 'Puppo' или всички с first_name = 'Kendra', но идентифицирането на точното число „Kendra Puppo“ изисква пресичане на тези множества, което не е толкова ефективно, колкото може би се надявате.

По-доброто решение е многоколонен индекс, който следва най-селективния и често използван модел на търсене:

Създаване на индекс: CREATE INDEX fullnames ON employees(last_name, first_name);

След като изпълните отново EXPLAIN, би трябвало да видите, че този индекс се използва, type подобрява се до нещо подобно ref или дори const в зависимост от уникалността и rows пада до 1. Това потвърждава, че е необходимо да се докосне само един ред, което обяснява огромното подобрение в производителността.

Подобен модел се появява и при оптимизацията на съединенията. Да предположим, че имате две таблици A и B със споделена колона X, използвана за обединяване, и първоначално ги създавате без индекси:

схема: CREATE TABLE A ( X VARCHAR(10), Y VARCHAR(10));
CREATE TABLE B ( X VARCHAR(10), Z VARCHAR(10));

Изпълнението на join с филтър върху AX може да покаже пълни сканирания както на A, така и на B, всяко с около 10 000 проверени реда, защото енджина няма по-добра опция от това да сравнява редове чрез груба сила:

Заявка за присъединяване: EXPLAIN SELECT *
FROM A INNER JOIN B ON A.X = B.X
WHERE A.X = '100';

След като добавите подходящи индекси и ограничения на външни ключове, EXPLAIN отразява подобрената стратегия. Например:

Индекс и FK: CREATE UNIQUE INDEX a_unique_index ON A(X);
CREATE UNIQUE INDEX b_unique_index ON B(X);
ALTER TABLE B ADD CONSTRAINT fk_b_x FOREIGN KEY (X) REFERENCES A(X);

След тези промени, EXPLAIN обикновено ще показва type подобряване (напр. eq_ref на присъединената маса), както и rows спадайки от хиляди до около 1, което доказва, че съединението сега използва ефикасни търсения в индекси, вместо да сканира всичко.

Съпоставяне на шаблони, сортиране и други често срещани клопки

EXPLAIN е особено ценен при работа с шаблони, сортиране и групиране, където на пръв поглед безобидният SQL може напълно да деактивира индексите. Ранното разпознаване на тези модели ви спестява много догадки.

Един класически проблем е съпоставянето на шаблони с водещи заместващи символи. Например, заявка с WHERE email LIKE '%yahoo.com' прави невъзможно създаването на стандартен индекс на email за да помогне, защото MySQL няма начин да прескача директно към редове, завършващи с този суфикс. EXPLAIN обикновено ще покаже type = ALL и голяма rows броя.

Завършващи заместващи символи, като например LIKE 'john%', са удобни за индексиране, защото двигателят може да използва индекса, за да намери диапазона от редове, започващи с „john“. EXPLAIN ще потвърди това, като покаже добър тип достъп и малък rows оценка на индексираната колона.

Сортирането и групирането са друга гореща точка за производителност. Ако се покаже ОБЯСНЕНИЕ Using filesort in Extra заедно с голям rows приблизителна оценка, вашата ORDER BY или GROUP BY вероятно налага изрична стъпка на сортиране.

Пример за сортиране: EXPLAIN SELECT sale_id FROM sales ORDER BY sale_date;

Добавяне на индекс към sale_date позволява на MySQL да чете редове директно в сортиран ред, което EXPLAIN обикновено отразява чрез премахване на Using filesort и евентуално промяна на типа достъп на index или по-добре.

В същото време внимавайте да не прекалявате с индексирането. EXPLAIN може да ви покаже кои индекси се появяват в possible_keys но никога не се използват като key от всяка важна заявка. Те може да са кандидати за премахване, но първо трябва да проверите общото натоварване; само защото една заявка игнорира индекс, не означава, че други критични заявки не разчитат на него.

ПОКАЗВАНЕ НА ПРЕДУПРЕЖДЕНИЯ и маркери за разширени обяснения

Когато заявка, дадена чрез EXPLAIN, дори не се анализира правилно, все още можете да извлечете известна информация, използвайки SHOW WARNINGS;. Тази команда показва информация за последното недиагностично твърдение и може да ви даде частични насоки за това как MySQL е интерпретирал фрагменти от вашата заявка.

Например, ако изпълните EXPLAIN върху заявка, която препраща към несъществуваща таблица или съдържа синтактична грешка, EXPLAIN може да се провали, но SHOW WARNINGS все още може да разкрие вътрешни маркери, показващи как ще бъдат третирани части от заявката. Може да видите маркери като:

• <index_lookup>(query fragment): предполага, че за този фрагмент ще се извърши търсене в индекса, ако заявката е валидна.
• <primary_index_lookup>(query fragment): показва, че ще се извърши търсене, базирано на първичен ключ.
• <if>(condition, expr1, expr2): посочва условна оценка в тази част на заявката.
• <temporary table>: показва създаването на вътрешна временна таблица за междинни резултати, например преди съединение.

Комбинирането на EXPLAIN EXTENDED с SHOW WARNINGS е мощен начин да видите не само плана, но и пренаписаната заявка на оптимизатора, която понякога разкрива опростявания, избутване на предикати или други трансформации, които може да не очаквате.

Отвъд EXPLAIN: модел на данни, архитектура и инструменти

Въпреки че EXPLAIN е фантастичен микроскоп за индивидуални заявки, устойчивата производителност зависи и от цялостния ви модел на данни, системна архитектура и хардуер. Не можете да поправите фундаментално лоша схема или претоварен екземпляр само чрез промяна на клаузите where.

Добра отправна точка е модел на данни, който разделя много различните работни натоварвания и Обработка на JSON в SQL. Например, смесването на регистрационни файлове за достъп с голям обем данни за транзакции в един и същ MySQL екземпляр е рецепта за дългосрочни проблеми: с разрастването на компанията, трафикът за регистриране може да насити входно-изходните операции и да влоши критичните бизнес заявки. Разделянето на регистрационни файлове в специално хранилище или хранилище за данни често е по-мащабируемо.

Софтуерната архитектура също играе важна роля. Решенията относно монолитни спрямо микросървиси, хранилища за данни и специализирани магазини (като графови бази данни за препоръки) ще повлияят на това какъв тип заявки ще изпълнявате и къде. Ако дадена услуга се нуждае от анализи в почти реално време на огромни набори от данни, стандартен OLTP MySQL екземпляр може да не е най-добрата цел за тези заявки.

Хардуерът и размерът на инстанцията също са от значение. Дисковият входно-изходен трафик, паметта, процесорът и мрежовата пропускателна способност влияят върху латентността на заявките. Идентифицирането на периоди на пиково натоварване и планирането на тежки аналитични или административни заявки извън тези прозорци може да защити производителността, насочена към потребителя. С управлявани DBaaS предложения често можете да мащабирате инстанции или да преминете към по-производителни класове, ако е необходимо.

Накрая, допълнете EXPLAIN с инструменти за непрекъснато наблюдение и профилиране. Собствена схема за производителност и лог за бавни заявки на MySQL, MySQL Workbench, Percona Toolkit pt-query-digest, уеб инструменти като EverSQL и платформи като Releem могат автоматично да изведат наяве най-лошите ви нарушители и дори да предложат оптимизации. EXPLAIN е вашият хирургически инструмент за тези специфични запитвания.

Добавянето на EXPLAIN и EXPLAIN ANALYZE към вашия инструментариум ви позволява да спрете да гадаете за бавни заявки и да започнете да разсъждавате с конкретни доказателства. Чрез разбиране на идентификаторите, типовете селект, методите за достъп, използването на индекси, оценките на редовете, филтрите и допълнителните флагове, можете методично да премахвате пълните сканирания на таблици, да контролирате скъпите съединения, да проектирате по-интелигентни индекси и да избягвате разточителни сортировки и временни таблици, като същевременно следите по-голямата картина на дизайна на схемата и инфраструктурата, така че вашите MySQL натоварвания да останат бързи и предвидими с нарастването си.