Лошата производителност на базата данни е трън в очите на всеки DBA. И не винаги е лесно да се изолира основната причина за проблемите с производителността, което само увеличава стреса.
Настройването на вашите бази данни на SQL Server е чудесен начин да разрешите някои от проблемите ви с производителността, но може да не винаги е очевидно откъде трябва да започнете процеса на оптимизация. Ако изключите дисковото пространство, паметта и други убийци на производителността на мрежата и хардуера, а производителността на вашия SQL Server все още изостава, е време да се задълбочите във вашите заявки.
Неоптимизираните заявки могат да причинят безброй проблеми с производителността на вашите системи. От добрата страна, няколко често срещани грешки в заявката са отговорни за по-голямата част от влошаването на производителността на базата данни.
Ако вашите заявки страдат от някой от тези шест проблема, пригответе се за сериозна настройка на производителността.
Проблемна заявка № 1:Подобни изрази с водещи заместващи знаци
Водещите заместващи знаци пречат на MySQL да използва индекси, принуждавайки пълно сканиране на таблицата, дори ако сте индексирали поле в таблицата. Сканирането на всички редове в таблицата значително забавя доставката на резултатите от заявката ви, така че премахнете водещия заместващ знак, за да подобрите ефективността.
Проблемна заявка № 2:Неиндексирани колони, използвани в клаузите „Къде“ и „Групиране по“
Индексирането на колони помага за по-бързото връщане на резултатите от заявката, тъй като елиминира необходимостта от пълно сканиране на таблицата. Индексирането също помага за сортирането на записите, когато се връщат, и гарантира, че тези записи са уникално идентифицирани, което е особено полезно в таблици с повече от 10 реда.
За малко перспектива, помислете за стартиране на изявление „explain“ в анализа на заявката си преди и след индексирането. Това ще ви даде представа колко реда сканиране сте си запазили току-що.
Проблемна заявка № 3:Подобни изявления, които използват оператора „или“ вместо клауза за съюз
Изпълняването на заявки с помощта на оператора за сравнение „или“ върху полета или колони в таблица може да бъде полезно, но прилагането на „или“ твърде често в клауза „където“ е друг бърз път към пълно сканиране на таблицата.
Клауза за съюз може да накара SQL заявката да се изпълнява по-бързо, особено ако различни индекси оптимизират всяка страна на заявката. По същество операторът на съюза взема резултатите от две бързи, индексирани заявки и ги слива в една.
Проблемна заявка № 4:Търсене със заместващи знаци
Ако сте заседнали в ситуация, в която трябва да търсите със заместващи знаци, но не искате да постигнете удара на производителността, опитайте да използвате пълнотекстово търсене на MySQL. Търсенето в пълен текст е значително по-бързо от търсенето със заместващи знаци и получавате допълнителното предимство от по-подходящи резултати, когато търсите огромни бази данни.
Проблемна заявка № 5:Неоптимизирана схема на база данни
Можете да подобрите производителността на SQL заявката толкова много, ако не оптимизирате и вашата схема на база данни. Ето няколко съвета за подобрение:
Нормализирайте таблиците
Резервирането на данни вреди на производителността, така че не забравяйте да представите факт само веднъж в базата данни. Например, ако препращате към клиент в повече от една таблица, използвайте „customer_name“ само веднъж, след това използвайте „customer_ID“ за последващи препратки.
Използвайте оптимални типове данни
Някои важни точки, които трябва да запомните, когато става въпрос за типове данни:
- По-късо е по-добре при проектирането на таблици. Например, използвайте тип данни „TINYINT“ за полето „user_id“ за таблица с потребители на системата с по-малко от 100 потребители.
- Използвайте тип данни „date_time“, ако полето очаква стойност за дата, така че да не се налага да конвертирате записите във формат на дата след факта.
- MySQL работи по-добре с целочислени стойности, отколкото с текстови типове данни, включително varchar.
Избягвайте нулеви стойности
Нулевите стойности в колона могат да навредят на резултатите от заявката ви, така че може да се наложи да зададете стойност по подразбиране за полета, където записите не изискват задължителна стойност.
Не използвайте твърде много колони
Широките таблици (повече от 100 колони) изискват много процесор и ресурси за обработка. Освен ако не трябва абсолютно да включите широка таблица, по-добре е да я разделите на по-малки, логически таблици.
Оптимизиране на присъединяванията
SQL изрази с твърде много обединения (и съединения с твърде много таблици) влияят негативно на производителността. Снимайте за не повече от 12 обединявания за всяка заявка.
Проблемна заявка № 6:Некеширани MySQL заявки
Уебсайтове и приложения, които изпълняват много избрани заявки, ще се възползват от кеширането на MySQL заявки. Кеширането на MySQL заявки ускорява производителността по време на операции за четене, тъй като кешира заявката за избор заедно с резултантния набор от данни и извлича от паметта (не от диска), ако заявката се изпълнява повече от веднъж.
Настройката на производителността е от съществено значение за поддържане на висока наличност за вашите бази данни на SQL Server и гарантиране, че вашите крайни потребители са доволни. Но за съжаление, не винаги е очевидно веднага къде настройката е най-необходима. Ако сте елиминирали очевидните мрежови и хардуерни източници за проблеми с производителността, преместете фокуса си върху заявките си.
Ако сте работили като DBA за определен период от време, вероятно сте се сблъсквали с една (или всички) от тези проблемни заявки. Сега, когато знаете за какво да внимавате, бъдете проактивни в инициативата си за подобряване на производителността и коригирайте тези често срещани болкови точки, за да можете да извлечете наградите от оптимизацията на заявките на SQL Server.
