Съдържание
Има момент, когато работим с бази данни, че вече не просто получаваме информацията, която ни засяга, а как я получаваме, тъй като в зависимост от конструкцията на заявката това ще бъде количеството ресурси, които нашата заявка консумира, за това PostgreSQL ни предлага ОБЯСНИ инструмент, с който виждаме как се изпълнява нашата заявка и всичко, което представлява.ОБЯСНИ И ОБЯСНИ АНАЛИЗ
Тези два инструмента са основната база при търсене на проблемите с производителността на заявките, които извършваме, въпреки тяхната полезност, те не са нещо ново, тъй като са включени в PostgreSQL От ранните си години, но това не означава, че са остарели или остарели, напротив, те са узрели, за да се превърнат в инструмент, способен да изготвя най -подробни доклади за изпълнението на заявки, включително резултатите, предоставени от инструмента, могат да бъдат получени във формати като XML или JSON за по -късен анализ с други инструменти.
В pgAdmin имаме налична опция за получаване на графика на резултата от ОБЯСНИ така че вместо да анализираме числа, можем да видим графика и по този начин по -лесно да открием проблемите на заявката и възможностите за подобрение.
Разлики между EXPLAIN и EXPLAIN ANALYZE
Може би и двата термина се използват така, сякаш са едно и също нещо, но между тях имаме различия, например ОБЯСНИ ни дава представа как планиращият заявки възнамерява да изпълни заявката, но вместо това не я изпълнява ОБЯСНИ АНАЛИЗ ако го изпълните и той ни дава сравнение между очакваното изпълнение и реалното представяне, получено при изпълнението. При стартиране ОБЯСНИ чрез pgAdmin Можем да избираме между EXPLAIN и EXPLAIN ANALYZE, което ще ни даде резултата от всеки от тях, докато ги избираме
Нека да видим пример за това как да използваме този инструмент, за това ще използваме ОБЯСНИ АНАЛИЗ, нека видим следния код:
ОБЯСНЕТЕ АНАЛИЗ ИЗБЕРЕТЕ вляво (тракт_ид, 5) Като окръг_код, SUM (hispanic_or_latino) Като tot, SUM (white_alone) As tot_white, SUM (coalesce (hispanic_or_latino, 0) - coalesce (white_alone, 0)) AS non_white GROP окръжен_код ***** ПО окръжен_код;
Това е много проста заявка, при която сумираме полетата, групата и реда според едно от полетата, което ще получим в резултат на анализа на производителността ще бъде следното:
GroupAggregate (цена = 111.29… 151.93 реда = 1478) (действително време = 6.099… 10.194 реда = 14 бримки = 1) -> Сортиране (цена = 111.29… 114.98 реда = 1478) (действително време = 5.897… 6.565 реда = 1478 цикъла = 1) Ключ за сортиране: ("вляво" ((тракт_ид) :: текст, 5)) Метод на сортиране: бърза сортиране на паметта: 136 kB -> Seq сканиране на hisp_pop (цена = 0,00… 33,48 реда = 1478) (действително време = 0,390… 2,693 редове = 1478 цикъла = 1) Общо време на изпълнение: 10,370 ms
Ако положим малко усилия за четене, резултатите постепенно стават по -лесни за четене, но ако нямаме много време или резултатът е много обширен, винаги можем да видим графиката.
Както виждаме, по -бързо се виждат резултатите на графично ниво, идеалното е да се използват и двата инструмента и да се допълват и двете гледни точки, това е една и съща информация само с различни ъгли, ще има пуристи, които искат само да работят с командната конзола и това е добре. Въпреки това, специалист по цялостна база данни трябва да използва всички инструменти, с които разполага, за да подобри работата си.
С това приключваме урока, с използването на тези инструменти вече ще сме в състояние да открием причините, които правят запитванията ни не бързи, или възможностите за подобрение, за да оптимизираме нашата заявка.Хареса ли ви и помогнахте на този урок?Можете да възнаградите автора, като натиснете този бутон, за да му дадете положителна точка