Лесно е да започнете да бърникате със съоръженията за оптимизация на SQL заявки. Отваряте SQL Server Management Studio (SSMS), наблюдавате времето за изчакване, преглеждате плана за изпълнение, събирате информация за обекта и започвате да оптимизирате SQL, докато не стартирате фино настроена машина.
Ако сте достатъчно добър в това, постигате бърза победа и се връщате към редовно планирания хаос. Но ако коригирате грешното нещо или коригирате правилното нещо в грешна посока, добре, сряда мина.
Оптимизация на SQL заявки? Какво ви кара да мислите, че имате нужда от него?
През повечето време това е скок в билетите за проблеми или оплакванията на потребителите. „Защо системата е толкова бавна?“ вашите потребители се оплакват. „Отнема ни цяла вечност, за да пуснем обичайните си отчети тази седмица.“
Това е доста смътно описание, разбира се. Би било хубаво, ако могат да ви кажат:„Нещата са бавни, защото имате имплицитно преобразуване в ред 62 на CurrentOrderQuery5.sql. Колоната е varchar и предавате цяло число." Но е малко вероятно потребителите ви да могат да видят това ниво на детайлност.
Поне билетите за проблеми и телефонните обаждания създават активен показател:лесен за забелязване, лесен за измерване. Когато започнат да се пускат, можете да сте доста сигурни, че е време за настройка на SQL.
Но има и други, пасивни показатели, които правят нуждата по-малко ясна. Неща като спад в продажбите, който може да се дължи на много фактори. Дали защото болезнено бавните заявки във вашия онлайн магазин карат клиентите ви да изоставят пазарските си колички? Дали защото икономиката е в лошо състояние?
Или може да са неща като бавна производителност на SQL Server. Дали защото една лошо написана заявка изпраща логически показания през покрива? Дали защото сървърът няма физически ресурси като памет и съхранение?
И в двата сценария оптимизацията на SQL заявки може да помогне с първата опция, но не и с втората.
Защо да приложите правилното решение към грешен проблем?
Преди да тръгнете по пътя на оптимизацията, уверете се, че настройката е правилното решение на правилния проблем.
Настройката на SQL е технически процес, но всяка техническа стъпка има корени в добрия бизнес смисъл. Бихте могли да прекарате дни, опитвайки се да съкратите времето за изпълнение с няколко милисекунди или да намалите броя на логическите четения с пет процента, но намаляването струва ли си времето? Вярно е, че е важно да се отговори на изискванията на потребителите, но всяко усилие в крайна сметка достига точката на намаляване на възвръщаемостта.
Помислете за тези проблеми с производителността на SQL заявки и бизнес контекста около тях:
- Приемлива производителност — Заявката се изпълнява за 10 минути и потребителят иска да се изпълни за една минута; това изглежда като разумно несъответствие и постижима цел за оптимизация. Ако обаче заявката отнеме една нощ и потребителят смята, че трябва да се изпълни за една минута, тогава това може да е нещо повече от проблем с настройката. От една страна, може да се наложи да образовате потребителя за количеството работа, която заявката действително извършва. От друга страна, може да е проблем с начина, по който е проектирана базата данни или начина, по който е написано клиентското приложение.
- Помощна програма — Да предположим, че отговаряте за администрирането на финансовата база данни в производствена компания. В края на всеки месец потребителите се оплакват от лошо представяне. Проследявате проблема до поредица от отчети в края на месеца, изготвени от Счетоводство, които отнемат часове всеки и отиват направо в картотеката, непроверена от никого. Вместо да настройвате, вие обяснявате проблема на бизнес мениджърите и получавате разрешение за изтриване на отчетите.
- Изместване на времето — Или да предположим, че същите тези доклади са важни за управлението, но не са спешни за бизнеса. Ако се изпълняват веднъж седмично или на месец, те могат да бъдат планирани за часове извън пиковите часове чрез предварително кеширане на набора от данни и изпращане на резултатите във файл. Това премахва пречките за другите бизнес потребители и освобождава потребителя на счетоводството от необходимостта да чака отчетите.
Когато вземете предвид бизнес контекста във вашето решение за оптимизиране, можете да зададете приоритети и да си спечелите време.
Когато оптимизирате SQL заявки, опитайте SQL диаграми
SSMS и инструментите, вградени в SQL Server, предлагат повечето от това, от което се нуждаете за ефективна оптимизация на SQL заявки. Комбинирайте инструментите с методичен подход около следните стъпки, както е описано в електронната книга „Основно ръководство за оптимизация на SQL заявки“:
- Време за изчакване на монитора
- Прегледайте плана за изпълнение
- Съберете информация за обекта
- Намерете масата за шофиране
- Определете инхибитори на производителността
В стъпка 4 вашата цел е да управлявате заявката с таблицата, която връща най-малко данни. Когато изучавате присъединяванията и предикатите и филтрирате по-рано в заявката, а не по-късно, намалявате броя на логическите четения. Това е голяма стъпка в оптимизирането на SQL заявки.
SQL диаграмирането е графична техника за картографиране на количеството данни в таблиците и намиране кой филтър ще върне най-малко записи. Първо, вие определяте кои таблици съдържат подробна информация и кои таблици са главните или справочните таблици. Помислете за простия пример за тази заявка към база данни за регистрация на университет:
Таблицата с подробности е регистрация. Има две справочни таблици, студент и клас. За да диаграмирате тези таблици, нарисувайте обърнато с главата надолу дърво, свързващо таблицата с подробности (в горната част) със стрелки (или връзки) към таблиците за търсене, както следва:
Сега изчислете относителния брой записи, необходими за критериите за присъединяване (тоест средното съотношение на редовете, свързани между таблицата с подробности и справочните таблици). Напишете числата във всеки край на стрелката. В този пример за всеки ученик има около 5 записа в регистрационната таблица, а за всеки клас има около 30 записа в регистрацията. Това означава, че никога не трябва да е необходимо да се ПРИСЪЕДИНЕТЕ към повече от 150 (5×30) записа, за да получите резултат за който и да е ученик или отделен клас.
Това упражнение е полезно, ако колоните ви за присъединяване не са индексирани или ако не сте сигурни, че са индексирани.
След това погледнете предикатите за филтриране, за да намерите с коя таблица да управлявате заявката. Тази заявка имаше два филтъра:единият при отменена регистрация =„N“, а другият при signup_date между две дати. За да видите колко селективен е филтърът, изпълнете тази заявка при регистрация:
изберете count(1) от регистрацията, където е отменено =‘N’
И r.signup_date МЕЖДУ :beg_date И :beg_date +1
Той връща 4 344 записа от общо 79 800 записа в регистрация. Тоест 5,43 процента от записите ще бъдат прочетени с този филтър.
Другият филтър е в клас:
изберете count(1) от клас, където име =‘ENGLISH 101’
Той връща два записа от 1000, или 0,2 процента, което представлява много по-селективен филтър. По този начин класът е основната таблица и тази, върху която първо трябва да фокусирате вашата SQL настройка.
Гласът на потребителя
Ако сте сигурни, че имате нужда от настройка на SQL, „Основното ръководство за оптимизиране на SQL заявки“ предлага допълнителна информация. Той ви превежда през пет съвета за настройка на производителността със заявки за копиране и поставяне и казуси, включително описания по-горе.
Вероятно ще откриете, че единственият най-важен инструмент за оптимизиране на SQL заявки е гласът на потребителя. Защо? Защото този глас ви позволява да знаете кога да започнете да оптимизирате и ви казва кога сте оптимизирали достатъчно. Може да ви гарантира, че ще започнете да бърникате със скоростите, когато трябва, и ще спрете, докато все още сте напред.
