{"id":18889,"date":"2026-04-10T08:34:12","date_gmt":"2026-04-10T06:34:12","guid":{"rendered":"https:\/\/webhosting.de\/datenbank-deadlock-detection-handling-hosting-infrastructure\/"},"modified":"2026-04-10T08:34:12","modified_gmt":"2026-04-10T06:34:12","slug":"wykrywanie-zakleszczen-bazy-danych-obsluga-infrastruktury-hostingowej","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/datenbank-deadlock-detection-handling-hosting-infrastructure\/","title":{"rendered":"Wykrywanie i obs\u0142uga impasu bazy danych w hostingu: przyczyny, rozwi\u0105zania i najlepsze praktyki"},"content":{"rendered":"<p>W \u015brodowiskach hostingowych <strong>mysql deadlock<\/strong>-Sytuacje, w kt\u00f3rych kilku klient\u00f3w wsp\u00f3\u0142dzieli CPU, RAM i I\/O, w wyniku czego blokady pozostaj\u0105 aktywne przez d\u0142u\u017cszy czas. Pokazuj\u0119 przyczyny, szybkie wykrywanie i elastyczn\u0105 obs\u0142ug\u0119, dzi\u0119ki czemu aplikacja reaguje niezawodnie na szczyty obci\u0105\u017cenia, a transakcje przebiegaj\u0105 bez powolnych \u0142a\u0144cuch\u00f3w oczekiwania.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Przyczyny<\/strong>D\u0142ugie transakcje, brakuj\u0105ce indeksy, zapytania N+1, wysokie poziomy izolacji<\/li>\n  <li><strong>Uznanie<\/strong>Automatyczne detektory, wykres impasu, kody b\u0142\u0119d\u00f3w i metryki<\/li>\n  <li><strong>Unikanie<\/strong>Sp\u00f3jna sekwencja blokad, kr\u00f3tkie zapytania, odpowiednia izolacja<\/li>\n  <li><strong>Hosting<\/strong>Zasoby wsp\u00f3\u0142dzielone rozszerzaj\u0105 blokady, pooling i rezerwy IOPS.<\/li>\n  <li><strong>Obs\u0142uga<\/strong>Logika ponawiania pr\u00f3b z backoffem, timeoutami i rozs\u0105dnymi priorytetami<\/li>\n<\/ul>\n\n<h2>Co tak naprawd\u0119 powoduje impas w hostingu?<\/h2>\n\n<p>A <strong>Martwy punkt<\/strong> wyst\u0119puje, gdy transakcje czekaj\u0105 na siebie cyklicznie: A ma X i chce Y, B ma Y i chce X. We wsp\u00f3\u0142dzielonych \u015brodowiskach hostingowych, wsp\u00f3\u0142dzielony procesor, wsp\u00f3\u0142dzielona pami\u0119\u0107 RAM i powolne I\/O wyd\u0142u\u017caj\u0105 czas trwania transakcji. <strong>Zamki<\/strong>, co oznacza, \u017ce takie cykle wyst\u0119puj\u0105 znacznie cz\u0119\u015bciej. Niezoptymalizowane zapytania, brakuj\u0105ce indeksy i wzorce N+1 zwi\u0119kszaj\u0105 liczb\u0119 zablokowanych wierszy i czas ich blokowania. D\u0142ugie transakcje, kt\u00f3re wci\u0105\u017c zawieraj\u0105 zewn\u0119trzne wywo\u0142ania, znacznie pogarszaj\u0105 sytuacj\u0119. Podczas szczyt\u00f3w ruchu ka\u017cde op\u00f3\u017anienie spowalnia kolejne \u017c\u0105dania, powoduj\u0105c reakcje \u0142a\u0144cuchowe z d\u0142ugimi czasami oczekiwania.<\/p>\n\n<h2>Cztery warunki w zwi\u0119z\u0142y i jasny spos\u00f3b<\/h2>\n\n<p>Aby dosz\u0142o do zaci\u015bni\u0119cia, musz\u0105 zosta\u0107 spe\u0142nione cztery warunki: <strong>Wzajemno\u015b\u0107<\/strong> Wykluczenie, wstrzymanie i oczekiwanie, brak wycofania i okr\u0119\u017cna relacja oczekiwania. W bazach danych oznacza to zwykle wy\u0142\u0105czne blokady wierszy lub stron, kt\u00f3re transakcja utrzymuje w oczekiwaniu na dalsze zasoby. Silnik nie usuwa tych blokad na si\u0142\u0119, wi\u0119c sytuacja utrzymuje si\u0119 do momentu rozpoznania konfliktu. Gdy tylko zostanie utworzony \u0142a\u0144cuch ko\u0142owy A\u2192B\u2192C\u2192A, nikt nie mo\u017ce kontynuowa\u0107. Je\u015bli specjalnie os\u0142abisz te cztery bloki konstrukcyjne, znacznie zmniejszysz wsp\u00f3\u0142czynnik zakleszcze\u0144.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/serverraum-deadlock-handling-7841.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wykrywanie impasu i automatyczna obs\u0142uga w MySQL i SQL Server<\/h2>\n\n<p>MySQL i SQL Server automatycznie rozpoznaj\u0105 cykle i wybieraj\u0105 <strong>Ofiara<\/strong>, \u017ce silnik si\u0119 cofa. MySQL cz\u0119sto sygnalizuje konflikt za pomoc\u0105 SQLSTATE 40001, kt\u00f3ry traktuj\u0119 jako wyzwalan\u0105 ponown\u0105 pr\u00f3b\u0119 w aplikacji. SQL Server u\u017cywa w\u0105tku monitora, kt\u00f3ry znacznie skraca interwa\u0142 sprawdzania w przypadku du\u017cej rywalizacji, aby szybciej reagowa\u0107. Ponadto <strong>DEADLOCK_PRIORITY<\/strong> w SQL Server, aby mniej wa\u017cne sesje ust\u0119powa\u0142y pierwsze\u0144stwa. W MySQL unikam zbyt d\u0142ugich skan\u00f3w, aby detektor nie musia\u0142 sprawdza\u0107 niepotrzebnie du\u017cej liczby kraw\u0119dzi. Je\u015bli rozumiesz automatyczny wyb\u00f3r ofiary, mo\u017cesz zbudowa\u0107 czyst\u0105 logik\u0119 powt\u00f3rze\u0144 i znacznie ustabilizowa\u0107 przepustowo\u015b\u0107.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Silnik<\/th>\n      <th>Uznanie<\/th>\n      <th>Wyb\u00f3r ofiary<\/th>\n      <th>Przydatne parametry\/sygna\u0142y<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>MySQL (InnoDB)<\/td>\n      <td>Wewn\u0119trzny <strong>Kontrola cyklu<\/strong> na Lock-Graph<\/td>\n      <td>Odwr\u00f3cenie oparte na kosztach<\/td>\n      <td>innodb_deadlock_detect, SQLSTATE 40001, PERFORMANCE_SCHEMA<\/td>\n    <\/tr>\n    <tr>\n      <td>SQL Server<\/td>\n      <td>Monitor z dynamiczn\u0105 blokad\u0105 <strong>Interwa\u0142<\/strong><\/td>\n      <td>Oparte na kosztach i priorytetach<\/td>\n      <td>DEADLOCK_PRIORITY, B\u0142\u0105d 1205, Zdarzenia rozszerzone<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Strategie: projektowanie transakcji, indeksy, izolacja<\/h2>\n\n<p>Trzymam transakcje kr\u00f3tko, naciskam <strong>Logika biznesowa<\/strong> i zdalnych wywo\u0142a\u0144 z sekcji krytycznej i tabel dost\u0119pu w sp\u00f3jnej kolejno\u015bci. Brakuj\u0105ce <strong>Wska\u017aniki<\/strong> i u\u017cywam EXPLAIN, aby sprawdzi\u0107, czy sekwencje z\u0142\u0105cze\u0144 i filtry s\u0105 poprawne. W MySQL redukuj\u0119 blokady next-key, je\u015bli zapytania zakresowe nie wymagaj\u0105 dodatkowej ochrony i ustawiam READ COMMITTED tam, gdzie to mo\u017cliwe. Planuj\u0119 wsp\u00f3\u0142czynniki wype\u0142nienia dla tabel intensywnie zapisuj\u0105cych, aby podzia\u0142y stron blokowa\u0142y si\u0119 rzadziej. Zmniejszenie rozmiaru cz\u0119stych skan\u00f3w i standaryzacja sekwencji blokad zapobiega wielu zakleszczeniom przed pierwsz\u0105 ponown\u0105 pr\u00f3b\u0105. Podsumowuj\u0119 szczeg\u00f3\u0142y dotycz\u0105ce zapyta\u0144 i indeks\u00f3w w praktyczny spos\u00f3b: <a href=\"https:\/\/webhosting.de\/pl\/wydajnosc-bazy-danych-zapytania-indeksy-blokowanie-serverboost\/\">Zapytania i indeksy<\/a>.<\/p>\n\n<h2>Rozs\u0105dne korzystanie z buforowania i replik odczytu<\/h2>\n\n<p>Skrytki zdejmuj\u0105 presj\u0119 <strong>Klawisze skr\u00f3tu<\/strong> takich jak sesje, koszyki lub flagi funkcji, aby nie ka\u017cda operacja odczytu wyzwala\u0142a kosztown\u0105 blokad\u0119. Repliki odczytu s\u0142u\u017c\u0105 jako korektory, ale monitoruje op\u00f3\u017anienie replikacji i ostro\u017cnie kontroluj\u0119 udzia\u0142y odczytu. Wysokie op\u00f3\u017anienie generuje ci\u015bnienie wsteczne, kt\u00f3re ostatecznie ponownie obci\u0105\u017ca podstawow\u0105 baz\u0119 danych. Geograficznie bli\u017csza pami\u0119\u0107 podr\u0119czna zmniejsza liczb\u0119 podr\u00f3\u017cy w obie strony, a tym samym czas utrzymywania blokad. Spojrzenie na timeouty pomaga w obci\u0105\u017ceniu: <a href=\"https:\/\/webhosting.de\/pl\/timeout-bazy-danych-hosting-powoduje-limity-serwera-dbcheck\/\">Limity czasu bazy danych w hostingu<\/a> pokazuj\u0105, dlaczego zharmonizowane warto\u015bci graniczne zapobiegaj\u0105 awariom. Uwzgl\u0119dnienie pami\u0119ci podr\u0119cznych, replik i limit\u00f3w czasu jako zestawu znacznie zmniejsza liczb\u0119 zakleszcze\u0144.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/besprechung_deadlock_8923.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pooling, zarz\u0105dzanie zasobami i ponawianie pr\u00f3b<\/h2>\n\n<p>Ograniczam liczb\u0119 jednoczesnych <strong>Pracownik<\/strong> poprzez pule po\u0142\u0105cze\u0144 i kontrolowanie d\u0142ugo\u015bci kolejek, dzi\u0119ki czemu aplikacja jest redukowana w kontrolowany spos\u00f3b pod obci\u0105\u017ceniem. Kr\u00f3tkie timeouty zapobiegaj\u0105 zawieszaniu si\u0119 sesji i zajmowaniu ca\u0142ych pul. Po wyst\u0105pieniu impasu przechwytuj\u0119 b\u0142\u0105d, czekam na jittering backoff i restartuj\u0119 transakcj\u0119 do g\u00f3rnego limitu. Planuj\u0119 rezerwy IOPS na wsp\u00f3\u0142dzielonej pami\u0119ci masowej, poniewa\u017c powolne wycofywanie spowalnia og\u00f3ln\u0105 przepustowo\u015b\u0107. Narz\u0119dzia do ograniczania obci\u0105\u017cenia w warstwie aplikacji zapobiegaj\u0105 doprowadzaniu bazy danych do trwa\u0142ych konflikt\u00f3w w godzinach szczytu.<\/p>\n\n<h2>Diagnostyka: dzienniki, metryki i wykres impasu<\/h2>\n\n<p>Na potrzeby analizy przyczyn \u017ar\u00f3d\u0142owych zbieram <strong>Kody b\u0142\u0119d\u00f3w<\/strong>, op\u00f3\u017anienia P95, czasy oczekiwania na blokad\u0119 i wykresy martwych punkt\u00f3w. W MySQL, Slow-Query-Log i PERFORMANCE_SCHEMA dostarczaj\u0105 informacji o bie\u017c\u0105cych blokadach. Wykres pokazuje, kto trzyma kogo, w jakiej kolejno\u015bci zostali zablokowani i kt\u00f3re zapytania s\u0105 zbyt szerokie. Domniemana sesja ofiary cz\u0119sto posiada najd\u0142u\u017csze blokady lub dzia\u0142a bez odpowiedniego indeksu. Po ka\u017cdej poprawce uruchamiam kr\u00f3tki test obci\u0105\u017ceniowy, aby sprawdzi\u0107, czy pojawiaj\u0105 si\u0119 nowe w\u0105skie gard\u0142a.<\/p>\n\n<h2>Parametry MySQL i znacz\u0105ce warto\u015bci domy\u015blne<\/h2>\n\n<p>Ustawi\u0142em <strong>innodb_lock_wait_timeout<\/strong> dzi\u0119ki czemu zablokowane sesje ko\u0144cz\u0105 si\u0119 niepowodzeniem w odpowiednim czasie przed powi\u0105zaniem pracownik\u00f3w. Pozostawiam w\u0142\u0105czon\u0105 funkcj\u0119 innodb_deadlock_detect, ale zmniejszam rywalizacj\u0119 poprzez lepsze indeksy i mniejsze partie, je\u015bli detektor zu\u017cywa du\u017co procesora. Standaryzowane limity czasu wzd\u0142u\u017c \u015bcie\u017cki \u017c\u0105dania zapobiegaj\u0105 sprzecznym sytuacjom oczekiwania. W SQL Server u\u017cywam DEADLOCK_PRIORITY i LOCK_TIMEOUT specjalnie dla zada\u0144 podatnych na konflikty. Ma\u0142e, ukierunkowane korekty oparte na zmierzonych warto\u015bciach zapewniaj\u0105 lepsze wyniki ni\u017c du\u017ce, uog\u00f3lnione zmiany.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/deadlock-detection-handling-blog-9273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rzeczywisto\u015b\u0107 hostingowa: specjalne funkcje serwer\u00f3w wsp\u00f3\u0142dzielonych<\/h2>\n\n<p>Hosty wsp\u00f3\u0142dzielone wyd\u0142u\u017caj\u0105 czas utrzymywania <strong>Zamki<\/strong>, poniewa\u017c fragmenty procesora, alokacja pami\u0119ci RAM i wej\u015bcia\/wyj\u015bcia konkuruj\u0105 ze sob\u0105. Pami\u0119\u0107 podr\u0119czna ukrywa pewne s\u0142abo\u015bci podczas codziennej pracy, ale nag\u0142e skoki obci\u0105\u017cenia ujawniaj\u0105 je. Nieoczyszczone wtyczki i brakuj\u0105ce indeksy zwi\u0119kszaj\u0105 liczb\u0119 zablokowanych linii, a nast\u0119pnie prowadz\u0105 do seryjnych zakleszcze\u0144. Je\u015bli planujesz ruch, rezerwuj przepustowo\u015b\u0107 i testuj wieczorne scenariusze za pomoc\u0105 narz\u0119dzi obci\u0105\u017ceniowych. Konkretne informacje na temat deadlock\u00f3w w hostingu podsumowa\u0142em tutaj: <a href=\"https:\/\/webhosting.de\/pl\/baza-danych-deadlocks-hosting-locktest-serverboost\/\">Martwe punkty w hostingu<\/a>.<\/p>\n\n<h2>Unikaj anty-wzorc\u00f3w, wybieraj lepsze wzorce<\/h2>\n\n<p>Szeroko\u015b\u0107 <strong>WYBIERZ ... DO AKTUALIZACJI<\/strong> bez w\u0105skiej klauzuli WHERE blokuj\u0105 zbyt wiele wierszy i generuj\u0105 ostr\u0105 konkurencj\u0119. ORMy z dost\u0119pem N+1 lub niepotrzebne UPDATE niezauwa\u017calnie pogarszaj\u0105 sytuacj\u0119. W przypadku kolejek polegam na parze indeks\u00f3w (status, created_at) i pracuj\u0119 w ma\u0142ych partiach zamiast u\u017cywa\u0107 MIN(id) bez odpowiedniego indeksu. Tabele zawieraj\u0105ce tylko dodatki wymagaj\u0105 regularnego przycinania i partycjonowania, aby konserwacja nie blokowa\u0142a du\u017cych tabel. Czyste sekwencje blokad i kr\u00f3tkie transakcje tworz\u0105 codzienny nawyk, kt\u00f3ry utrzymuje deadlocki na niskim poziomie.<\/p>\n\n<h2>Idempotentna logika biznesowa i bezpieczne ponawianie pr\u00f3b<\/h2>\n\n<p>Ponowne pr\u00f3by s\u0105 odporne tylko wtedy, gdy projekt <strong>idempotentny<\/strong> jest. Przypisuj\u0119 unikalny identyfikator \u017c\u0105dania dla ka\u017cdej transakcji biznesowej i zapisuj\u0119 go w dedykowanej kolumnie lub tabeli dziennika. Druga pr\u00f3ba rozpoznaje identyfikator, kt\u00f3ry zosta\u0142 ju\u017c przetworzony i pomija efekt uboczny. Dla proces\u00f3w zapisu u\u017cywam <strong>UPSERT<\/strong>-pattern (np. INSERT ... ON DUPLICATE KEY UPDATE lub MERGE w SQL Server) i hermetyzowa\u0107 efekty uboczne (np. e-maile, webhooki) poza transakcj\u0105 lub uczyni\u0107 je r\u00f3wnie\u017c idempotentnymi.<\/p>\n\n<pre><code>\/\/ Pseudokod: Retry z jittering backoff + idempotency\nmaxAttempts = 5\nfor attempt in 1..maxAttempts {\n  try {\n    beginTx()\n    ensureIdempotencyKey(requestId) \/\/ unikalne ograniczenie\n    \/\/ ... lean, zmiany oparte na indeksach ...\n    commit()\n    break\n  } catch (Deadlock|SerialisationError e) {\n    rollback()\n    if (attempt == maxAttempts) throw e\n    sleep(jitteredBackoff(attempt)) \/\/ 50-500ms, z jitterem\n  }\n}\n<\/code><\/pre>\n\n<p>Ograniczam r\u00f3wnie\u017c konkurencj\u0119 w ukierunkowany spos\u00f3b: przetwarzam gor\u0105ce klawisze seryjnie (poprzez muteks\/blokad\u0119 doradcz\u0105) lub rozk\u0142adam obci\u0105\u017cenie poprzez hash buckets. W ten spos\u00f3b ponawianie pr\u00f3b nie tylko zmniejsza liczb\u0119 b\u0142\u0119d\u00f3w, ale tak\u017ce p\u00f3\u017aniejsze obci\u0105\u017cenie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/deadlock_detection_techoffice_4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tryby wersjonowania i izolacji wierszy w szczeg\u00f3\u0142ach<\/h2>\n\n<p>W bloku MySQL pod <strong>POWTARZALNE CZYTANIE<\/strong> Blokady Next-Key nie tylko chroni\u0105 dotkni\u0119te wiersze, ale tak\u017ce luki w indeksie. Chroni to przed fantomowymi odczytami, ale zwi\u0119ksza prawdopodobie\u0144stwo zakleszczenia podczas skanowania zakresu. Tam, gdzie to mo\u017cliwe, ustawiam <strong>READ COMMITTED<\/strong> aby zredukowa\u0107 blokady luk i przekszta\u0142ci\u0107 zapytania w celu selektywnego dopasowania prefiks\u00f3w indeks\u00f3w. W SQL Server <strong>ODCZYT ZATWIERDZONEJ MIGAWKI<\/strong> (RCSI) i <strong>SNAPSHOT<\/strong> Odczyt oparty na MVCC bez blokad odczytu; konflikty zapisu pozostaj\u0105, ale martwe punkty staj\u0105 si\u0119 rzadsze. Mam oko na Tempdb\/Version Store, aby wersjonowanie wierszy nie sta\u0142o si\u0119 nowym w\u0105skim gard\u0142em.<\/p>\n\n<p>W przypadku licznik\u00f3w, zapas\u00f3w i sald kont ustawiam jasne, kr\u00f3tkie aktualizacje kluczy podstawowych. Z\u0142o\u017cone obliczenia przenosz\u0119 przed lub po transakcji. Wa\u017cne jest, aby ka\u017cda transakcja dotyka\u0142a jak najmniej i blokowa\u0142a si\u0119 w sp\u00f3jnej kolejno\u015bci.<\/p>\n\n<h2>Usuwanie hotspot\u00f3w: Model danych i sharding<\/h2>\n\n<p>Wiele zakleszcze\u0144 wyst\u0119puje w <strong>Hotspoty<\/strong>globalne liczniki, scentralizowane linie statusu, monotoniczne identyfikatory. Rozk\u0142adam obci\u0105\u017cenie za pomoc\u0105 hash lub partycjonowania czasowego (np. na klienta, na dzie\u0144) i unikam singleton\u00f3w. W MySQL sprawdzam <strong>innodb_autoinc_lock_mode<\/strong>Interleaved (2) redukuje auto-increment-contention dla r\u00f3wnoleg\u0142ych INSERT. W przypadku sekwencji lub numer\u00f3w bilet\u00f3w u\u017cywam wst\u0119pnie przydzielonych blok\u00f3w na pracownika, aby nie ka\u017cda alokacja blokowa\u0142a centraln\u0105 tabel\u0119.<\/p>\n\n<p>Wyb\u00f3r klucza r\u00f3wnie\u017c ma znaczenie: Z\u0142o\u017cone klucze podstawowe, kt\u00f3re mapuj\u0105 naturalny wymiar dost\u0119pu (np. account_id + id) prowadz\u0105 do w\u0105skich, ukierunkowanych blokad. Szerokie identyfikatory UUID s\u0105 w porz\u0105dku, je\u015bli s\u0105 randomizowane, a podzia\u0142y indeks\u00f3w pozostaj\u0105 \u0142atwe w zarz\u0105dzaniu.<\/p>\n\n<h2>Partie, projektowanie zada\u0144 i SKIP LOCKED<\/h2>\n\n<p>Planuj\u0119 prac\u0119 w tle w <strong>ma\u0142e partie<\/strong> (np. 100-500 wierszy) i u\u017cywa\u0107 stabilnego sortowania za pomoc\u0105 klucza g\u0142\u00f3wnego. W MySQL 8.0 pomaga <strong>NOWAIT\/SKIP ZABLOKOWANE<\/strong>, aby pomija\u0107 linie blokuj\u0105ce zamiast gromadzi\u0107 kolejki. W SQL Server ustawi\u0142em <strong>READPAST<\/strong> z <strong>UPDLOCK<\/strong> oraz <strong>ROWLOCK<\/strong> post\u0119powa\u0107 w podobny spos\u00f3b.<\/p>\n\n<pre><code>-- MySQL: Wyci\u0105ganie zada\u0144 bez blokowania\nSELECT id FROM jobs\n WHERE status = 'ready'\n ORDER BY id\n LIMIT 200\n DLA AKTUALIZACJI POMI\u0143 ZABLOKOWANE;\n\n-- SQL Server: Podobny wzorzec\nSELECT TOP (200) id FROM jobs WITH (ROWLOCK, UPDLOCK, READPAST)\n WHERE status = 'ready'\n ORDER BY id;\n<\/code><\/pre>\n\n<p>Rozbijam du\u017ce, monolityczne przebiegi konserwacyjne na kroki, kt\u00f3re mo\u017cna wznowi\u0107. Skraca to czas utrzymywania blokady, a krajobraz zada\u0144 pozostaje solidny nawet po ponownym uruchomieniu.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/datenbank_deadlock_8736.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strategie migracji i DDL bez przestoj\u00f3w<\/h2>\n\n<p>Zmiany schematu mog\u0105 powodowa\u0107 gigantyczne blokady. W MySQL zwracam uwag\u0119 na <strong>ALGORITHM=INPLACE<\/strong> oraz <strong>LOCK=NONE<\/strong>, gdy tylko jest to mo\u017cliwe, i migruj\u0119 kolumny w dw\u00f3ch krokach (utw\u00f3rz nowe, wype\u0142nij, prze\u0142\u0105cz). W SQL Server u\u017cywam <strong>ONLINE=ON<\/strong> (Przedsi\u0119biorstwo) oraz, w stosownych przypadkach. <strong>WAIT_AT_LOW_PRIORITY<\/strong>, dzi\u0119ki czemu ruch odczytu\/zapisu jest kontynuowany. D\u0142ugotrwa\u0142e operacje DDL blokuj\u0119 czasowo, wstrzymuj\u0119 je przy szczytowym obci\u0105\u017ceniu i wznawiam w kontrolowany spos\u00f3b. Przed ka\u017cd\u0105 migracj\u0105 tworz\u0119 plan B (\u015bcie\u017cka wycofania) i mierz\u0119 oczekiwane koszty we\/wy na kopii.<\/p>\n\n<p>Dodaj\u0119 indeksy w spos\u00f3b ukierunkowany: najpierw dla cz\u0119stych warunk\u00f3w filtrowania, a nast\u0119pnie dla kluczy JOIN. Ka\u017cdy dodatkowy indeks kosztuje czas zapisu - zbyt wiele indeks\u00f3w wyd\u0142u\u017ca transakcje, a tym samym zwi\u0119ksza ryzyko zakleszczenia i wymagania dotycz\u0105ce pami\u0119ci.<\/p>\n\n<h2>Testowanie i odtwarzanie zakleszcze\u0144<\/h2>\n\n<p>Do debugowania buduj\u0119 minimalne <strong>powtarzalny<\/strong> Scenariusze z dwiema sesjami: Sesja A blokuje wiersz X, a nast\u0119pnie uzyskuje dost\u0119p do Y, sesja B robi to na odwr\u00f3t. Wymuszam kolizj\u0119 z kr\u00f3tkimi SLEEPS mi\u0119dzy instrukcjami. W ten spos\u00f3b weryfikuj\u0119 hipotezy z wykresu deadlock. W MySQL obserwuj\u0119 PERFORMANCE_SCHEMA (events_transactions_current, data_locks) r\u00f3wnolegle, w SQL Server odpowiednie rozszerzone zdarzenia. Nast\u0119pnie zmieniam indeksy, filtry i sekwencje, a\u017c impas zniknie.<\/p>\n\n<p>Takie testy powinny by\u0107 przeprowadzane w CI: ma\u0142e skoki obci\u0105\u017cenia, kt\u00f3re \u0142\u0105cz\u0105 uruchomienia wsadowe i grafik\u0119 online, wcze\u015bnie wykrywaj\u0105 b\u0142\u0119dy sekwencji blokad. Wa\u017cne: u\u017cywaj tej samej puli i warto\u015bci limitu czasu co w produkcji, w przeciwnym razie przegapisz prawdziwy problem.<\/p>\n\n<h2>Obserwowalno\u015b\u0107 i ostrzeganie: od sygna\u0142u do dzia\u0142ania<\/h2>\n\n<p>Prowadz\u0119 kilka, wyra\u017anych <strong>Sygna\u0142y<\/strong> z: Deadlocks\/minut\u0119, czas oczekiwania na blokad\u0119 P95\/P99, procent ponawianych transakcji i czas trwania commitu P95. Uruchamiam alerty, gdy wska\u017aniki s\u0105 zwi\u0119kszone w pewnym okresie czasu (np. &gt;5 deadlock\u00f3w\/minut\u0119 w ci\u0105gu 10 minut) i z kontekstem: kt\u00f3re tabele, kt\u00f3re zapytania, kt\u00f3re wdro\u017cenia by\u0142y uruchomione. Oddzielam pulpity nawigacyjne wed\u0142ug \u015bcie\u017cek odczytu\/zapisu; mapy cieplne pokazuj\u0105, kiedy wyst\u0119puje najwi\u0119cej konflikt\u00f3w (czas, okno wsadowe).<\/p>\n\n<p>Dla natychmiastowej miary definiuj\u0119 <strong>Runbooki<\/strong>Zmniejszenie limit\u00f3w puli, wstrzymanie wadliwych zada\u0144 wsadowych, tymczasowe zwi\u0119kszenie TTL pami\u0119ci podr\u0119cznej, przeniesienie obci\u0105\u017cenia odczytu na repliki, wyg\u0142adzenie okien zapisu. Po tym nast\u0119puje praca nad przyczyn\u0105 \u017ar\u00f3d\u0142ow\u0105: dodanie indeksu, przebudowanie zapytania, rozbrojenie modelu danych, dostosowanie poziomu izolacji.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/hosting-serverraum-5743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kr\u00f3tko i jasno: w ten spos\u00f3b utrzymuj\u0119 deadlocki na niskim poziomie<\/h2>\n\n<p>Priorytetem jest dla mnie kr\u00f3tki <strong>Transakcje<\/strong>, sp\u00f3jne sekwencje blokad i odpowiednie poziomy izolacji, aby blokady by\u0142y szybko zwalniane. Czyste indeksy i oszcz\u0119dne zapytania skracaj\u0105 czas trwania ka\u017cdej krytycznej fazy. Pami\u0119ci podr\u0119czne i repliki odczytu zmniejszaj\u0105 obci\u0105\u017cenie podstawowej bazy danych, je\u015bli mam oko na op\u00f3\u017anienia replikacji. Pula po\u0142\u0105cze\u0144, timeouty i logika ponawiania pr\u00f3b z backoffem zapewniaj\u0105, \u017ce poszczeg\u00f3lne konflikty nie przerywaj\u0105 przep\u0142ywu. Ci\u0105g\u0142e monitorowanie za pomoc\u0105 wykresu impasu, P95 i oczekiwania na blokad\u0119 pokazuje odchylenia na wczesnym etapie, dzi\u0119ki czemu mog\u0119 podj\u0105\u0107 \u015brodki zaradcze, zanim u\u017cytkownicy cokolwiek zauwa\u017c\u0105.<\/p>","protected":false},"excerpt":{"rendered":"<p>Kompleksowy przewodnik po wykrywaniu zakleszcze\u0144 mysql i blokad baz danych w hostingu. Strategie, diagnostyka i obs\u0142uga stabilnych baz danych.<\/p>","protected":false},"author":1,"featured_media":18882,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-18889","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"462","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"mysql deadlock","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18882","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=18889"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18889\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/18882"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=18889"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=18889"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=18889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}