Експертите знаят как да пишат ефективни заявки. Въпреки че опитът узрява мъдростта, има някои неща, които човек трябва да разбере поне за начало. Например, трябва да разберете основните съображения за дизайна на заявката; как се изпълнява вътрешната заявка, къде е неуспешна, модели за оптимизация и т.н. В тази статия ще предоставя няколко точки за оптимизация, върху които да обмислите, докато проектирате заявка в MySQL.
Защо някои заявки са бавни?
Често срещан проблем със SQL заявките е, че се извличат повече данни, отколкото са действително необходими. Разбира се, има заявки, които пресяват много данни и не можем да направим много за тях, но те не са често срещани. В повечето случаи лошият дизайн на заявката води до лоша производителност на заявката. След всеки дизайн на заявката трябва да се вгледате в няколко аспекта като това, което може да се случи след задействане на заявката:
- Ще има ли SQL заявката достъп до твърде много колони или редове?
- Сървърът MySQL ще анализира ли твърде много редове, за да извлече желания резултат?
Има заявки, които карат MySQL сървъра да анализира твърде много данни, но ги хвърля, докато пресява. Това е допълнителна работа за сървъра по отношение на много аспекти като мрежови разходи, твърде много консумация на памет или твърде много използване на ресурсите на процесора на сървъра. Последствието е бавно изпълнение.
Има ситуации, при които може да не сте в състояние да помогнете много по време на неговото проектиране, но има ситуация, при която ако сте внимателни и прецените последствията и се интроспектирате, тогава една лоша заявка може поне да бъде подобрена, ако не и по-добра.
Типични грешки и техните решения
Има доста често срещани грешки при писане на заявка. Ето няколко от тях. Можете да намерите още няколко мисли в същия ред. Ето причините за бавната производителност на заявките с възможни решения.
Твърде много редове
Често се прави грешка при написването на заявка, която извлича данни и приема, че MySQL ще предостави резултат при поискване, като същевременно пренебрегва количеството обработка, необходима за връщане на пълния набор от резултати. Да предположим, че операторът SELECT се задейства за извличане на подробности за 100 продукта за сайт за електронна търговия, когато само 10 от тях всъщност трябва да бъдат показани първи. Може да си помислите, че MySQL извлича само 10 реда и спира да изпълнява заявката. Но не. Това, което MySQL прави, е да генерира пълния набор от резултати и да захранва клиента. Клиентската библиотека получава пълния комплект и изхвърля по-голямата част от него и запазва само 10 от които търси. Това очевидно губи много ресурси.
В такава ситуация обаче можете да предоставите решение, като използвате клаузата LIMIT със заявката.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
Клаузата LIMIT приема един или два параметъра. Първият определя отместването, а вторият определя броя. Ако е посочен само един параметър, той обозначава броя на редовете от началото на набора от резултати.
Например, за да изберете 10 реда от таблицата, можете да напишете:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
А за избор на следващите 10 реда, започвайки от 11 запис, можете да напишете:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Твърде много колони
Винаги гледайте заявката:SELECT * с подозрение. Тази заявка връща всички колони и вероятно имате нужда само от някои от тях. Най-големият недостатък на извличането на всички колони е, че предотвратява оптимизацията, като възпрепятства използването на индекси, изисква твърде много I/O, памет и ресурси на процесора от сървъра.
Разберете, че такава универсална заявка, извличаща всички колони, може да бъде разточителна. Някои казват, че са полезни, защото позволяват на разработчиците да използват един и същ бит код на повече от едно място. Това е добре, ако съответните разходи са ограничени в рамките на разглеждане. Понякога кеширането на извлечените данни помага в този контекст. Но бъдете внимателни, използването на производителност е лъскава работа и такъв лукс може да няма място за представяне.
Основното правило е да избягвате подобни универсални заявки или да поддържате броя на колоните, извлечени до минимален възможно.
Твърде много анализ на данни
Заявките връщат желания резултат, това е добре, но понякога тези заявки са написани по такъв начин, че докато обработват, изискват изследване на твърде много данни, преди да се генерират резултати. Следователно в MySQL трябва да измервате според следните показатели за разходите:
- Време за изпълнение
- Редовете са проверени
- Колоните са проверени
Можете да получите груба оценка на цената на заявката от тези показатели. Те отразяват количеството достъп до данни от MySQL вътрешно за обработка на заявката и колко бързо се изпълнява заявката. Тъй като тези показатели се записват в бавния регистър на заявките, добра идея е да проучите и да намерите заявки, които анализират твърде много данни, за да върнат резултата. MySQL базата данни регистрира всички заявки, които надвишават определено време за изпълнение в бавния дневник на заявките. Това е идеално място да търсите бавни заявки и да разберете колко често са бавни.
Бавен регистър на заявките обикновено се намира в /var/log/mysql/mysql-slow.log
Имайте предвид, че може да се наложи да зададете и разрешите регистрирането на бавни заявки в mysqld.cnf конфигурационен файл, както следва.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Преди и с MySQL 5 имаше сериозни ограничения, особено липсата на поддръжка за фино регистриране. Единственото отсрочка беше използването на пачове, които позволяваха регистриране. Функцията обаче е част от сървърите MySQL 5.1 и по-нови като част от основната й функция.
Заявките, които отнемат твърде много време при изпълнение, не означават непременно, че са лоши заявки. Бавният дневник на заявките просто предоставя възможност да се изследва ефективността на заявката и да се подобри възможно най-добре.
Заявки за преструктуриране
Тъй като имате възможност да преструктурирате проблемни заявки, основната ви цел трябва да бъде намирането на алтернативно решение за постигане на желания ефект. Можете да трансформирате заявката в нейната еквивалентна форма, като имате предвид вътрешния ефект в MySQL сървъра по време на обработката.
Едно решение при дизайна на заявката е дали да предпочетем една сложна заявка вместо няколко прости или обратно. Конвенционалният подход за проектиране на база данни е да се извършват възможно най-много работи с по-малко заявки. Причината е, че една голяма/сложна заявка е по-рентабилна по отношение на установяване на връзка с базата данни. Предимството на намаляването на разходите в полза на сложната заявка е използването на мрежата, обработката/оптимизацията на заявките и използването на ресурсите. Но този традиционен подход не се вписва добре с MySQL. MySQL е проектиран да обработва бързо свързване и прекъсване на връзката с базата данни. Следователно, установяването на връзка, задействането на много по-прости заявки и затварянето на връзката изглежда по-ефективно. Извличането на данни чрез повече от една проста заявка вместо една голяма сложна е по-ефективно. Имайте предвид, че същата идея може да не се прилага с други бази данни.
Заключение
Това са няколко бързи съвета за оптимизиране на заявките. Разберете, че познаването на синтаксиса на SQL, способността да създадете заявка, която извлича желания резултат, не е достатъчна, ако човек се стреми към ефективност на заявката. Разбирането на случващото се под привидно простите изглеждащи заявки е жизненоважно за писането на такива, които не само извличат желаното, но и вдъхват изкуството на оптимизацията точно откъдето започва всичко. Задкулисното случване на обработката на заявки дава важна улика за разбиране на ефективността на заявката и тези познания са задължителни преди един набег в сферата на оптимизацията на заявки.
