Съдържание
Когато правим кратни запитвания В сложна система много пъти не предприемаме подходящия път, за да имаме оптимална производителност на ниво база данни, с настоящия технологичен напредък и изчислителната мощ, която често виждаме в нашите сървъри, можем да мислим, че оптимизацията на базата данни е въпрос на минало.Това не може да бъде по-далеч от истината, въпреки напредъка в мощността на оборудването, базите данни са от основно значение за работата на приложенията, поради което добре написаната и силно оптимизирана заявка може да означава няколко секунди натоварване, което спестява в системата, ако умножим това по броя на едновременните потребители, виждаме как се губят разходите и мощността.
Оптимизиране на заявки
Най -добрият начин да подобрим производителността на нашите бази данни е да започнем с добре написани заявки, много пъти установяваме, че заявките не са добре написани, тъй като не са толкова оптимизирани, колкото би трябвало, има много причини за това, една от тях е повторната употреба без осъзнаване на кода; С това имаме предвид, че ако в даден момент направим заявка, която работи за нас с a ляво присъединяване Ще продължим да го прилагаме, когато увеличаваме броя на таблиците, които трябва да бъдат консултирани, когато го променяме и променяме някои клаузи от вътрешно съединение Това може да съкрати пътя и да спести консумацията на процесор.
SQL е език, който въпреки че е доста лесен за четене, има много аспекти и много вариации, които ни позволяват да направим нещо, което работи по най -добрия и най -лошия начин, от нас зависи да знаем как да идентифицираме дали нашето решение принадлежи на категория или друга.
За да знаем, че сме на прав път, едно от най -важните неща е да се актуализира, тоест не можем да продължим кодирането в SQL в рамките на PostgreSQL сякаш това беше първата версия, когато сме в версия 9.
За използването на подзаявки
Това е една от най -често срещаните грешки, които правим, и това е, че мислим за заявка като набор от части, които смесваме заедно, докато не получим краен резултат, но това поведение оказва силно влияние върху производителността на нашата база данни.
Нека да видим пример за това типично поведение:
SELECT tractor_id, (SELECT COUNT (*) FROM. факти F КЪДЕ F.tract_id = T.tract_id)) Като num_fact_types ОТ преброяване.lu_tracts As T;
Сега, ако видим графиката на ОБЯСНИ От тази заявка ще разберем колко скъпо е да го направите по този начин:
Увеличете
SELECT T.tract_id, COUNT (f.fact_type_id) Като num_facts, COUNT (DISTINCT fact_type_id) Като num_fact_types ОТ преброяване.lu_tracts Като T ОСТАВЕТЕ ПРИСЪЕДИНЯВАНЕ на преброяване.факти като F ON T.tract_id = F.tract_id ГРУПА ПО T.tract_id;
В тази нова версия на нашата заявка избягваме използването на подзаявки, вместо това правим еквивалент с ляво присъединяване Y Групирай поАко видим графиката, можем да кажем разликата.
Увеличете
