Znajdź kosztowne żądanie zanim zmienisz bazę danych
Zacznij od działania użytkownika: załadowanie kategorii, wyszukanie artykułu, dodanie do koszyka lub złożenie zamówienia. Zarejestruj jego ścieżkę, liczbę zapytań, czas spędzony w bazie, zwrócone wiersze oraz czas trwania żądania. Wolna strona może też oczekiwać na kod aplikacji lub inne zależności, więc nie diagnozuj tylko na podstawie czasu ładowania strony.
Plan zapytania to trasa bazy danych przez tabele, indeksy, łączenia, sortowania i agregaty. W PostgreSQL EXPLAIN pokazuje tę trasę. EXPLAIN ANALYZE uruchamia instrukcję i raportuje rzeczywiste wiersze oraz czasy, dlatego użyj bezpiecznego reprezentatywnego zapytania. Duża rozbieżność między szacowanymi a rzeczywistymi wierszami jest powodem do zbadania statystyk lub warunków, nie automatycznym żądaniem indeksu.
Powiąż kandydackie zapytanie ze ścieżką i wynikiem, aby sam raport dashboardu nie miał większego priorytetu niż wolny checkout.
Zarejestruj czasy przed zmianą i porównywalny ruch bez logowania identyfikatorów klientów, tokenów ani danych kart.
Projektuj indeksy dla rzeczywistej ścieżki dostępu
Indeks to utrzymywana struktura, która może pomóc odnaleźć wiersze lub zwrócić je w kolejności; to nie uniwersalny przełącznik przyspieszający. Zacznij od filtrów, kluczy łączeń i porządku SORT ważnego zapytania, a potem potwierdź proponowany indeks w planie. Dokumentacja PostgreSQL opisuje, że dopasowany indeks B‑tree może spełnić ORDER BY bez osobnego sortowania, szczególnie z małym LIMIT.
Indeksy dodają miejsce na dysku i pracę przy zapisach, bo INSERT, UPDATE i DELETE je utrzymują. Dla zapytania potrzebującego dużego ułamka tabeli skan sekwencyjny i jawne sortowanie może być szybsze. Testuj na danych podobnych do produkcji i zachowaj indeks tylko wtedy, gdy jego korzyść uzasadnia koszt.
Użyj rzeczywistych filtrów zapytania i ORDER BY, łącznie z deterministycznym tie‑breakerem tam, gdzie interfejs potrzebuje stabilnego porządku.
Sprawdź, czy indeks jest używany i jaki powoduje koszt przy zapisach; weryfikuj ponownie w miarę zmiany danych i ruchu.
Uczyń paginację stabilną i przystępną kosztowo
Paginacja oparta na numerze strony zwykle używa LIMIT razem z OFFSET. Zawsze narzucaj przewidywalny porządek. PostgreSQL ostrzega, że bez ORDER BY LIMIT może zwrócić nieprzewidywalny podzbiór; różne wartości LIMIT lub OFFSET mogą dawać niespójne podzbiory, ponieważ optymalizator może wybierać różne plany.
Duże offsety wymagają uwagi, ponieważ pominięte wiersze wciąż muszą być policzone. Dla głębokich katalogów, historii zamówień lub przeglądania archiwum rozważ paginację kursorową (keyset): żądaj wierszy po ostatniej widzianej stabilnej wartości sortowania i unikalnym tie‑breakerze. Zdefiniuj, jak pojawiają się nowe lub usunięte rekordy przed zmianą interfejsu.
Zwracaj najmniejszą użyteczną stronę zamiast nieograniczonego wyniku.
Zdecyduj, czy interfejs naprawdę potrzebuje dokładnego totalu przy każdym żądaniu.
Cache’uj pracę odczytową bez serwowania błędnej odpowiedzi
Cache ponownie wykorzystuje wcześniejszy wynik zamiast rekonstruować go z bazy. Zacznij od warstwy HTTP dla publicznych, powtarzalnych stron i wersjonowanych zasobów, ponieważ trafienie w cache może uniknąć pracy aplikacji i bazy. web.dev rekomenduje długotrwałe cache’owanie dla wersjonowanych URL‑i; zmiana URL jest praktycznym mechanizmem unieważniania.
Polityka cache to decyzja o poprawności. Wspólny cache może ponownie użyć jednej odpowiedzi dla wielu użytkowników, więc nie udostępniaj wyjścia specyficznego dla konta, koszyka, cen lub autoryzacji, chyba że jest zaprojektowane i przetestowane pod odpowiedni zakres. Cache‑Control private ogranicza ponowne użycie do cache przeglądarki, podczas gdy no‑store nakazuje, by cache w ogóle nie przechowywały odpowiedzi.
Oddziel publiczną zawartość katalogu lub artykułu od wyjścia specyficznego dla sesji, lokalizacji i uprawnień.
Zdefiniuj, kto może zobaczyć przeterminowaną wartość, przez jak długi czas oraz drogę unieważnienia lub rewalidacji.
Chroń pojemność połączeń zamiast po prostu podnosić sufit
Połączenie to aktywna sesja klienta do bazy danych. Workerzy, zadania cron, podglądy lub ponowienia mogą wyczerpać sloty nawet jeśli pojedyncze zapytania wyglądają dopuszczalnie. max_connections w PostgreSQL kontroluje równoczesne połączenia, jest ustawiane przy starcie serwera, a wyższa wartość alokuje więcej zasobów, w tym pamięć współdzieloną. Podnoszenie jej bez modelu obciążenia może przesunąć problem.
Ustal jeden budżet obejmujący web workerów, zadania w tle, administrację i repliki. Używaj bounded pooling tam, gdzie pasuje, zachowaj zapas na odzyskiwanie i stosuj timeouty, aby porzucone zadania nie czekały w nieskończoność. Bezpieczne liczby zależą od silnika, pamięci, miksu zapytań i limitów dostawcy; potwierdź je z operatorem.
Uwzględnij procesy webowe, kolejki, zadania zaplanowane, migracje, narzędzia raportujące i zadania wdrożeniowe.
Ogranicz współbieżność i stosuj backoff, by awaria nie mnożyła zapotrzebowania na połączenia.
Obserwuj koszt zapytań z kontekstem i kontrolami prywatności
Ranguj pracę bazy danych według całkowitego wpływu, a nie pojedynczego wolnego przykładu. Umiarkowanie wolne zapytanie wywoływane tysiące razy może mieć większe znaczenie niż rzadki raport. pg_stat_statements w PostgreSQL agreguje dane planowania i wykonania, w tym wywołania, całkowity i średni czas wykonania, wiersze i aktywność buforów. Wymaga konfiguracji serwera i restartu, by dodać lub usunąć; śledzenie planowania może dodać narzut.
Powiąż grupy zapytań ze ścieżką, wersją wydania i oknem czasowym. OpenTelemetry radzi zbierać tekst zapytania domyślnie tylko po jego sanitizacji, która zastępuje literały, oraz używać podsumowania o niskiej kardynalności do grupowania. To pomaga właścicielom widzieć trendy bez eksportowania danych klientów lub tworzenia etykiety dla każdej wartości.
Przeglądaj czas trwania, łączny czas, wywołania, błędy, połączenia i wiersze; każdy ujawnia inny tryb awarii.
Używaj zapytań parametryzowanych i weryfikuj, że literały są usuwane zanim ślady lub logi opuszczą aplikację.
Wdrażaj zmiany w bazie jako odwracalną pracę niezawodnościową
Traktuj indeks, przepisywanie zapytania, politykę cache, ustawienie puli lub zmianę schematu jako zmianę produkcyjną z właścicielem, miarą sukcesu i decyzją odwrócenia. Waliduj w reprezentatywnym środowisku, wydaj na ograniczonej części ruchu i obserwuj dotkniętą podróż. Szybciej nie znaczy sukces, jeśli zmiana zwraca błędne, brakujące, zduplikowane lub przeterminowane dane.
Zmiany schematu wymagają ostrożności, bo wersje aplikacji mogą zachodzić na siebie. Wytyczne Google Cloud opisują sekwencję zgodności: wypuść aplikację obsługującą stary i nowy schemat, zmień schemat, a potem wydaj funkcję, która go używa. To zachowuje możliwość rollbacku aplikacji. Zamykanie i zachowanie online‑change różni się według silnika i serwisu zarządzanego; uzyskaj kwalifikowaną recenzję dla systemów o dużym wolumenie lub związanych z płatnościami.
Nazwij ścieżkę, sygnały wydajności i poprawności oraz próg, który zatrzyma rollout.
Zweryfikuj wydajność i poprawność na kontrolowanym wycinku zanim poszerzysz; przećwicz drogę powrotu poza incydentem.