Ето удобния списък с неща, които винаги давам на някой, който ме пита за оптимизация.
Използваме основно Sybase, но повечето от съветите ще важат навсякъде.
SQL Server, например, идва с множество битове за наблюдение/настройка на производителността, но ако нямате нищо подобно (и може би дори да го имате), тогава бих помислил за следното...
99% от проблемите Виждал съм, че са причинени от поставяне на твърде много таблици в присъединяване . Поправката за това е да направите половината от присъединяването (с някои от таблиците) и да кеширате резултатите във временна таблица. След това извършете присъединяването на останалата част от заявката към тази временна таблица.
Контролен списък за оптимизиране на заявки
- Изпълнете UPDATE STATISTICS на основните таблици
- Много системи изпълняват това като планирана седмична работа
- Изтриване на записи от основните таблици (евентуално архивиране на изтритите записи)
- Помислете дали да не правите това автоматично веднъж на ден или веднъж седмично.
- Преизграждане на индекси
- Възстановяване на таблици (bcp данни изход/вход)
- Изхвърлете/презаредете базата данни (драстично, но може да коригира повреда)
- Създайте нов, по-подходящ индекс
- Изпълнете DBCC, за да видите дали има възможна повреда в базата данни
- Заключване/Заключване
- Уверете се, че в базата данни не се изпълняват други процеси
- Особено DBCC
- Използвате ли заключване на ниво ред или страница?
- Заключете таблиците изключително преди да започнете заявката
- Проверете дали всички процеси осъществяват достъп до таблици в същия ред
- Уверете се, че в базата данни не се изпълняват други процеси
- Използват ли се индексите по подходящ начин?
- Съединенията ще използват индекс само ако и двата израза са от един и същ тип данни
- Индексът ще се използва само ако първото(ите) поле(а) в индекса се съвпадат в заявката.
- Използват ли се клъстерирани индекси, където е уместно?
- данни за диапазона
- поле WHERE между стойност 1 и стойност 2
- Малките съединения са хубави връзки
- По подразбиране оптимизаторът ще разглежда само 4 таблици наведнъж.
- Това означава, че при обединения с повече от 4 таблици има добър шанс да избере неоптимален план за заявка
- Разбийте присъединяването
- Можете ли да развалите присъединяването?
- Предварително изберете външни ключове във временна таблица
- Направете половината от присъединяването и поставете резултатите във временна таблица
- Използвате ли правилния вид временна таблица?
#tempтаблиците могат да работят много по-добре от@tableпроменливи с големи обеми (хиляди редове).
- Поддържайте обобщени таблици
- Изграждане с тригери на основните таблици
- Изграждайте ежедневно/почасово/и т.н.
- Създайте ad hoc
- Изграждане постепенно или разрушаване/възстановяване
- Вижте какъв е планът на заявката с SET SHOWPLAN ON
- Вижте какво всъщност се случва със SET STATS IO ON
- Принудително въвеждане на индекс с помощта на прагмата:(индекс:myindex)
- Принудително подреждане на таблицата чрез SET FORCEPLAN ON
- Подушване на параметри:
- Разбийте съхранената процедура на 2
- извикайте proc2 от proc1
- позволява на оптимизатора да избере индекс в proc2, ако @parameter е променен от proc1
- Можете ли да подобрите хардуера си?
- В колко часа бягате? Има ли по-тихо време?
- Сървърът за репликация (или друг непрекъснат процес) работи ли? Можете ли да го спрете? Пуснете го напр. на час?
