PostgreSQL - Optymalizacja zapytań

Kiedy robimy wielokrotności zapytania W złożonym systemie wielokrotnie nie obieramy odpowiedniej drogi, aby uzyskać optymalną wydajność na poziomie bazy danych, przy obecnym postępie technologicznym i mocy obliczeniowej, którą często widzimy w naszych serwerach, możemy pomyśleć, że optymalizacja bazy danych to już przeszłość.
To nie może być dalsze od prawdy, pomimo zaawansowania sprzętu, bazy danych mają fundamentalne znaczenie dla wydajności aplikacji, dlatego dobrze napisane i wysoce zoptymalizowane zapytanie może oznaczać kilkusekundowe obciążenie, które oszczędza w system, jeśli pomnożymy to przez liczbę jednoczesnych użytkowników, zobaczymy, jak marnowane były koszty i moc.
Optymalizuj zapytania
Najlepszym sposobem na poprawę wydajności naszych baz danych jest rozpoczęcie od dobrze napisanych zapytań, wiele razy okazuje się, że zapytania nie są dobrze napisane, ponieważ nie są tak zoptymalizowane, jak powinny, jest wiele przyczyn tego stanu rzeczy, jedna z nich czy ponowne użycie bez świadomości kodu; Rozumiemy przez to, że jeśli w pewnym momencie wykonaliśmy zapytanie, które działa dla nas za pomocą a lewy dołączyć Będziemy go nadal stosować przy zwiększaniu liczby tabel do przeglądania, przy modyfikowaniu i zmienianiu niektórych klauzul o połączenie wewnętrzne Mogłoby to skrócić ścieżkę i zmniejszyć zużycie procesora.
SQL to język, który choć jest dość łatwy do odczytania, ma wiele aspektów i wiele odmian, które pozwalają nam zrobić coś, co działa najlepiej i najgorzej, to od nas zależy, jak rozpoznać, czy nasze rozwiązanie należy do kategorię lub inną.
Aby wiedzieć, że jesteśmy na dobrej drodze, jedną z najważniejszych rzeczy jest aktualizacja, czyli nie możemy kontynuować kodowania w SQL w ciągu PostgreSQL jakby to była pierwsza wersja, kiedy jesteśmy w wersja 9.
Informacje o korzystaniu z podzapytań
Jest to jeden z najczęściej popełnianych przez nas błędów, ponieważ myślimy o zapytaniu jako o zestawie elementów, które łączymy ze sobą, aż do uzyskania końcowego wyniku, jednak to zachowanie ma duży wpływ na wydajność naszej bazy danych.
Zobaczmy przykład tego typowego zachowania:

 SELECT tract_id, (SELECT COUNT (*) FROM census.facts As F WHERE F.tract_id = T.tract_id) As num_facts, (SELECT COUNT (*) FROM census.lu_fact_types As Y WHERE Y.fact_type_id IN (SELECT fact_type_id FROM spis. fakty F GDZIE F.tract_id = T.tract_id)) As num_fact_types FROM census.lu_tracts As T; 

Teraz, jeśli widzimy wykres WYJAŚNIAĆ Z tego zapytania dowiemy się, jak drogie jest zrobienie tego w ten sposób:

POWIĘKSZAĆ

Jak widać, mamy kilka punktów, które są wąskimi gardłami w tym zapytaniu, poza wszystkimi danymi, które trzeba nieefektywnie przenieść, w tym celu przepiszemy je w bardziej optymalny sposób i porównamy z nowym wykresem WYJAŚNIAĆ.

 SELECT T.tract_id, COUNT (f.fact_type_id) As num_facts, COUNT (DISTINCT fact_type_id) As num_fact_types FROM census.lu_tracts As T LEFT JOIN census.facts As F ON T.tract_id = F.tract_id GROUP BY T.tract_id; 

W nowej wersji naszego zapytania unikamy używania podzapytań, zamiast tego wykonujemy odpowiednik z lewy dołączyć Tak Grupuj wedługJeśli zobaczymy wykres, możemy powiedzieć różnicę.

POWIĘKSZAĆ

Widzimy, że droga do uzyskania naszego wyniku jest znacznie krótsza, co daje nam wyższą wydajność, nie oznacza to, że musimy wykluczyć podzapytania naszych narzędzi pracy, ale raczej musimy mieć świadomość, że mogą istnieją lepsze ścieżki do tego, co możemy w tej chwili zaproponować.Podobał Ci się i pomógł ten samouczek?Możesz nagrodzić autora, naciskając ten przycisk, aby dać mu pozytywny punkt