{"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":"detektering-av-doedlaege-i-databas-hantering-hosting-infrastruktur","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/datenbank-deadlock-detection-handling-hosting-infrastructure\/","title":{"rendered":"Detektering och hantering av databasd\u00f6dl\u00e4ge i hosting: orsaker, l\u00f6sningar och b\u00e4sta praxis"},"content":{"rendered":"<p>I v\u00e4rdmilj\u00f6er <strong>mysql d\u00f6dl\u00e4ge<\/strong>-Det kan uppst\u00e5 situationer d\u00e4r flera klienter delar CPU, RAM och I\/O och l\u00e5s f\u00f6rblir aktiva l\u00e4ngre som ett resultat av detta. Jag visar p\u00e5 orsaker, snabb uppt\u00e4ckt och smidig hantering s\u00e5 att din applikation reagerar tillf\u00f6rlitligt p\u00e5 belastningstoppar och transaktioner k\u00f6rs utan l\u00e5ngsamma v\u00e4ntkedjor.<\/p>\n\n<h2>Centrala punkter<\/h2>\n\n<ul>\n  <li><strong>Orsaker<\/strong>L\u00e5nga transaktioner, saknade index, N+1-fr\u00e5gor, h\u00f6ga isoleringsniv\u00e5er<\/li>\n  <li><strong>Erk\u00e4nnande<\/strong>Automatiska detektorer, deadlock-graf, felkoder och m\u00e4tv\u00e4rden<\/li>\n  <li><strong>Undvikande<\/strong>Konsekvent l\u00e5ssekvens, korta f\u00f6rfr\u00e5gningar, l\u00e4mplig isolering<\/li>\n  <li><strong>Hosting<\/strong>Delade resurser ut\u00f6kar l\u00e5s, pooling och IOPS-reserver hj\u00e4lper<\/li>\n  <li><strong>Hantering<\/strong>Logik f\u00f6r ompr\u00f6vningar med backoff, timeouts och rimliga prioriteringar<\/li>\n<\/ul>\n\n<h2>Vad utl\u00f6ser egentligen d\u00f6dl\u00e4gen i hosting<\/h2>\n\n<p>En <strong>D\u00f6dl\u00e4ge<\/strong> uppst\u00e5r n\u00e4r transaktioner v\u00e4ntar p\u00e5 varandra cykliskt: A har X och vill ha Y, B har Y och vill ha X. I delade hostingmilj\u00f6er f\u00f6rl\u00e4nger delad CPU, delat RAM-minne och l\u00e5ngsam I\/O varaktigheten f\u00f6r <strong>L\u00e5s<\/strong>, vilket inneb\u00e4r att s\u00e5dana cykler intr\u00e4ffar mycket oftare. Ooptimerade fr\u00e5gor, saknade index och N+1-m\u00f6nster \u00f6kar antalet blockerade rader och den tid under vilken de blockeras. L\u00e5nga transaktioner som fortfarande inneh\u00e5ller externa anrop f\u00f6rv\u00e4rrar situationen enormt. Under trafiktoppar bromsar varje f\u00f6rdr\u00f6jning upp ytterligare f\u00f6rfr\u00e5gningar, vilket resulterar i kedjereaktioner med l\u00e5nga v\u00e4ntetider.<\/p>\n\n<h2>De fyra villkoren kortfattat och tydligt<\/h2>\n\n<p>Fyra f\u00f6ruts\u00e4ttningar m\u00e5ste sammanfalla f\u00f6r en fastsp\u00e4nning: <strong>\u00d6msesidig<\/strong> Exkludering, h\u00e5ll-och-v\u00e4nta, inget uttag och ett cirkul\u00e4rt v\u00e4ntef\u00f6rh\u00e5llande. I databaser inneb\u00e4r detta vanligtvis exklusiva rad- eller sidl\u00e5s som en transaktion h\u00e5ller i v\u00e4ntan p\u00e5 ytterligare resurser. Motorn tar inte bort dessa l\u00e5s med v\u00e5ld, s\u00e5 situationen kvarst\u00e5r tills den uppt\u00e4cker en konflikt. S\u00e5 snart en cirkul\u00e4r kedja A\u2192B\u2192C\u2192A har skapats kan ingen forts\u00e4tta. Om du specifikt f\u00f6rsvagar dessa fyra byggstenar minskar du d\u00f6dl\u00e5sningsfrekvensen avsev\u00e4rt.<\/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>Detektering och automatisk hantering av d\u00f6dl\u00e4gen i MySQL och SQL Server<\/h2>\n\n<p>MySQL och SQL Server k\u00e4nner igen cykler automatiskt och v\u00e4ljer en <strong>Offret<\/strong>, att motorn rullar tillbaka. MySQL signalerar ofta konflikten med SQLSTATE 40001, som jag behandlar som en utl\u00f6sbar ompr\u00f6vning i applikationen. SQL Server anv\u00e4nder en monitortr\u00e5d som kraftigt f\u00f6rkortar kontrollintervallet i h\u00e4ndelse av h\u00f6g contention f\u00f6r att reagera snabbare. Dessutom \u00e4r <strong>DEADLOCK_PRIORITET<\/strong> i SQL Server s\u00e5 att mindre viktiga sessioner f\u00e5r ge vika f\u00f6rst. I MySQL undviker jag \u00f6verl\u00e5nga skanningar s\u00e5 att detektorn inte beh\u00f6ver kontrollera ett on\u00f6digt stort antal kanter. Om man f\u00f6rst\u00e5r det automatiska urvalet av offer kan man bygga en ren repetitionslogik och stabilisera genomstr\u00f6mningen m\u00e4rkbart.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Motor<\/th>\n      <th>Erk\u00e4nnande<\/th>\n      <th>Val av offer<\/th>\n      <th>Anv\u00e4ndbara parametrar\/signaler<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>MySQL (InnoDB)<\/td>\n      <td>Internt <strong>Cykel-kontroll<\/strong> p\u00e5 Lock-Graph<\/td>\n      <td>Kostnadsbaserad \u00e5terf\u00f6ring<\/td>\n      <td>innodb_deadlock_detect, SQLSTATE 40001, PERFORMANCE_SCHEMA<\/td>\n    <\/tr>\n    <tr>\n      <td>SQL Server<\/td>\n      <td>L\u00e5s monitor med dynamisk <strong>Intervall<\/strong><\/td>\n      <td>Kostnads- och prioritetsbaserad<\/td>\n      <td>DEADLOCK_PRIORITY, Fel 1205, Ut\u00f6kade h\u00e4ndelser<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Strategier: transaktionsdesign, index, isolering<\/h2>\n\n<p>Jag h\u00e5ller transaktionerna korta, trycker <strong>Aff\u00e4rslogik<\/strong> och fj\u00e4rrsamtal fr\u00e5n den kritiska sektionen och \u00e5tkomsttabellerna i en konsekvent ordning. Saknas <strong>Index<\/strong> och anv\u00e4nder EXPLAIN f\u00f6r att kontrollera om l\u00e4nkningssekvenser och filter \u00e4r korrekta. I MySQL minskar jag next-key-l\u00e5s om intervallfr\u00e5gor inte kr\u00e4ver ytterligare skydd och st\u00e4ller in READ COMMITTED d\u00e4r det \u00e4r m\u00f6jligt. Jag planerar fyllnadsfaktorer f\u00f6r skrivintensiva tabeller s\u00e5 att siduppdelningar l\u00e5ses mindre ofta. Genom att minska storleken p\u00e5 frekventa skanningar och standardisera l\u00e5ssekvenser kan m\u00e5nga blockeringar undvikas innan f\u00f6rsta f\u00f6rs\u00f6ket. Jag sammanfattar detaljer om fr\u00e5gor och index p\u00e5 ett praktiskt s\u00e4tt: <a href=\"https:\/\/webhosting.de\/sv\/databas-prestanda-fragor-index-lasning-serverboost\/\">Fr\u00e5gor och index<\/a>.<\/p>\n\n<h2>Anv\u00e4nd cachelagring och l\u00e4srepliker p\u00e5 ett f\u00f6rnuftigt s\u00e4tt<\/h2>\n\n<p>Cacher tar bort pressen <strong>Snabbknappar<\/strong> som sessioner, varukorgar eller funktionsflaggor, s\u00e5 att inte varje l\u00e4soperation utl\u00f6ser ett dyrt l\u00e5s. L\u00e4srepliker fungerar som utj\u00e4mnare, men jag \u00f6vervakar replikeringsf\u00f6rdr\u00f6jningen och kontrollerar l\u00e4sandelarna noggrant. En h\u00f6g f\u00f6rdr\u00f6jning genererar backpressure, vilket i slut\u00e4ndan belastar den prim\u00e4ra databasen igen. En geografiskt n\u00e4rmare cache minskar rundresor och d\u00e4rmed l\u00e5sens h\u00e5lltid. En titt p\u00e5 timeouts hj\u00e4lper till med belastningen: <a href=\"https:\/\/webhosting.de\/sv\/databas-timeout-hosting-orsaker-servergraenser-dbcheck\/\">Tidsgr\u00e4nser f\u00f6r databas i hosting<\/a> visar varf\u00f6r harmoniserade gr\u00e4nsv\u00e4rden f\u00f6rhindrar misslyckanden. Om man betraktar cacher, repliker och timeouts som en helhet minskar antalet deadlocks avsev\u00e4rt.<\/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>Poolning, resurshantering och omf\u00f6rs\u00f6k<\/h2>\n\n<p>Jag begr\u00e4nsar antalet samtidiga <strong>Arbetare<\/strong> via anslutningspooler och kontrollerar k\u00f6l\u00e4ngderna s\u00e5 att applikationen reduceras p\u00e5 ett kontrollerat s\u00e4tt under belastning. Korta timeouts f\u00f6rhindrar att h\u00e4ngande sessioner binder upp hela pooler. Efter ett d\u00f6dl\u00e4ge f\u00e5ngar jag upp felet, v\u00e4ntar p\u00e5 en jitterbackoff och startar om transaktionen upp till den \u00f6vre gr\u00e4nsen. Jag planerar IOPS-reserver p\u00e5 delad lagring, eftersom en l\u00e5ngsam rollback saktar ner den totala genomstr\u00f6mningen. Verktyg f\u00f6r belastningsbegr\u00e4nsning i applikationslagret f\u00f6rhindrar att topptider driver databasen in i permanenta konflikter.<\/p>\n\n<h2>Diagnostik: loggar, m\u00e4tv\u00e4rden och deadlock-graf<\/h2>\n\n<p>F\u00f6r analysen av grundorsaken samlar jag in <strong>Felkoder<\/strong>, P95-latency, l\u00e5sv\u00e4ntetider och titta p\u00e5 grafer \u00f6ver d\u00f6dl\u00e4gen. I MySQL ger Slow-Query-Log och PERFORMANCE_SCHEMA information om aktuella blockeringar. Grafen visar vem som h\u00e5ller vem, i vilken ordning de blockerades och vilka fr\u00e5gor som \u00e4r f\u00f6r breda. Den f\u00f6rmodade offersessionen har ofta de l\u00e4ngsta l\u00e5sen eller k\u00f6rs utan ett l\u00e4mpligt index. Efter varje fix startar jag ett kort belastningstest f\u00f6r att kontrollera om nya flaskhalsar uppst\u00e5r.<\/p>\n\n<h2>MySQL-parametrar och meningsfulla standardv\u00e4rden<\/h2>\n\n<p>Jag st\u00e4ller in <strong>innodb_lock_wait_timeout<\/strong> s\u00e5 att blockerade sessioner misslyckas i god tid innan de binder arbetare. Jag l\u00e5ter funktionen innodb_deadlock_detect vara aktiverad, men minskar konkurrensen genom b\u00e4ttre index och mindre batcher om detektorn tar upp mycket CPU-tid. Standardiserade timeouts l\u00e4ngs f\u00f6rfr\u00e5gningsv\u00e4gen f\u00f6rhindrar mots\u00e4gelsefulla v\u00e4ntesituationer. I SQL Server anv\u00e4nder jag DEADLOCK_PRIORITY och LOCK_TIMEOUT specifikt f\u00f6r konfliktben\u00e4gna jobb. Sm\u00e5, riktade justeringar baserade p\u00e5 uppm\u00e4tta v\u00e4rden ger b\u00e4ttre resultat \u00e4n stora, generella justeringar.<\/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>Verklighetens v\u00e4rd: specialfunktioner p\u00e5 delade servrar<\/h2>\n\n<p>Delade v\u00e4rdar f\u00f6rl\u00e4nger innehavstiden f\u00f6r <strong>L\u00e5s<\/strong>, eftersom CPU-slice, RAM-allokering och I\/O konkurrerar med varandra. Cacheminnet d\u00f6ljer vissa svagheter under den dagliga driften, men pl\u00f6tsliga belastningstoppar avsl\u00f6jar dem. Plugins som inte \u00e4r rena och index som saknas driver upp antalet blockerade linjer och leder sedan till seriella d\u00f6dl\u00e4gen. Om du planerar trafik, reservera kapacitet och testa kv\u00e4llsscenarier med belastningsverktyg. Jag har sammanfattat specifik bakgrundsinformation om deadlocks inom hosting h\u00e4r: <a href=\"https:\/\/webhosting.de\/sv\/databas-deadlocks-hosting-locktest-serverboost\/\">D\u00f6dl\u00e4gen i hosting<\/a>.<\/p>\n\n<h2>Undvik anti-m\u00f6nster, v\u00e4lj b\u00e4ttre m\u00f6nster<\/h2>\n\n<p>Bredd <strong>V\u00c4LJ ... F\u00d6R UPPDATERING<\/strong> utan en smal WHERE-klausul blockerar f\u00f6r m\u00e5nga rader och skapar h\u00e5rd konkurrens. ORM:er med N+1-\u00e5tkomst eller on\u00f6diga UPDATE:er f\u00f6rv\u00e4rrar situationen obem\u00e4rkt. F\u00f6r k\u00f6er f\u00f6rlitar jag mig p\u00e5 ett indexpar (status, created_at) och arbetar i sm\u00e5 satser ist\u00e4llet f\u00f6r att anv\u00e4nda MIN(id) utan ett l\u00e4mpligt index. Tabeller som bara inneh\u00e5ller bilagor kr\u00e4ver regelbunden besk\u00e4rning och liknande partitionering s\u00e5 att underh\u00e5llet inte l\u00e5ser stora tabeller. Tydliga l\u00e5ssekvenser och korta transaktioner utg\u00f6r den dagliga vanan som h\u00e5ller d\u00f6dl\u00e4gena sm\u00e5.<\/p>\n\n<h2>Idempotent aff\u00e4rslogik och s\u00e4kra ompr\u00f6vningar<\/h2>\n\n<p>Omf\u00f6rs\u00f6k \u00e4r bara m\u00f6jliga om designen <strong>idempotent<\/strong> \u00e4r. Jag tilldelar ett unikt f\u00f6rfr\u00e5gnings-ID f\u00f6r varje aff\u00e4rstransaktion och sparar det i en s\u00e4rskild kolumn eller journaltabell. Ett andra f\u00f6rs\u00f6k k\u00e4nner igen det ID som redan har behandlats och hoppar \u00f6ver bieffekten. F\u00f6r skrivprocesser anv\u00e4nder jag <strong>UPSERT<\/strong>(t.ex. INSERT ... ON DUPLICATE KEY UPDATE eller MERGE i SQL Server) och kapsla in sidoeffekter (t.ex. e-postmeddelanden, webhooks) utanf\u00f6r transaktionen eller g\u00f6ra dem idempotenta ocks\u00e5.<\/p>\n\n<pre><code>\/\/ Pseudokod: F\u00f6rs\u00f6k p\u00e5 nytt med jitterbackoff + idempotency\nmaxAttf\u00f6rs\u00f6k = 5\nf\u00f6r f\u00f6rs\u00f6k i 1..maxAttempts {\n  f\u00f6rs\u00f6k {\n    b\u00f6rjaTx()\n    ensureIdempotencyKey(requestId) \/\/ unik begr\u00e4nsning\n    \/\/ ... magra, indexbaserade \u00e4ndringar ...\n    commit()\n    break\n  } catch (Deadlock|SerialisationError e) {\n    rollback()\n    if (f\u00f6rs\u00f6k == maxAttempts) throw e\n    sleep(jitteredBackoff(attempt)) \/\/ 50-500 ms, med jitter\n  }\n}\n<\/code><\/pre>\n\n<p>Jag begr\u00e4nsar ocks\u00e5 konkurrenterna p\u00e5 ett m\u00e5linriktat s\u00e4tt: Jag bearbetar snabbtangenter seriellt (via mutex\/advisory lock) eller f\u00f6rdelar belastningen via hash buckets. P\u00e5 s\u00e5 s\u00e4tt minskar ompr\u00f6vningarna inte bara felen utan \u00e4ven den efterf\u00f6ljande belastningen.<\/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>Detaljerad beskrivning av versionering och isolering av rader<\/h2>\n\n<p>I MySQL-blocket under <strong>REPEATABLE READ<\/strong> Next-Key-Locks skyddar inte bara ber\u00f6rda rader, utan \u00e4ven luckor i indexet. Detta skyddar mot fantoml\u00e4sningar, men \u00f6kar sannolikheten f\u00f6r d\u00f6dl\u00e4ge under intervallskanningar. D\u00e4r det \u00e4r m\u00f6jligt st\u00e4ller jag in <strong>L\u00c4S BEKR\u00c4FTAD<\/strong> f\u00f6r att minska gap-l\u00e5s och omforma fr\u00e5gor f\u00f6r att selektivt matcha indexprefix. I SQL Server <strong>L\u00c4SA BEKR\u00c4FTAD \u00d6GONBLICKSBILD<\/strong> (RCSI) och <strong>SNAPSHOT<\/strong> MVCC-baserad l\u00e4sning utan l\u00e4sl\u00e5s; skrivkonflikter kvarst\u00e5r, men deadlocks blir mer s\u00e4llsynta. Jag h\u00e5ller ett \u00f6ga p\u00e5 Tempdb\/Version Store s\u00e5 att versionering av rader inte blir den nya flaskhalsen.<\/p>\n\n<p>F\u00f6r r\u00e4knare, lager och kontosaldon g\u00f6r jag tydliga, korta uppdateringar av prim\u00e4rnycklar. Jag flyttar komplexa ber\u00e4kningar f\u00f6re eller efter transaktionen. Det \u00e4r viktigt att varje transaktion ber\u00f6r s\u00e5 lite som m\u00f6jligt och l\u00e5ses i en konsekvent ordning.<\/p>\n\n<h2>Avv\u00e4rja hotspots: Datamodell och sharding<\/h2>\n\n<p>M\u00e5nga d\u00f6dl\u00e4gen uppst\u00e5r vid <strong>Hotspots<\/strong>globala r\u00e4knare, centraliserade statuslinjer, monotona ID:n. Jag f\u00f6rdelar belastningen med hash- eller tidspartitionering (t.ex. per kund, per dag) och undviker singletons. Med MySQL kontrollerar jag <strong>innodb_autoinc_lock_mode<\/strong>Interleaved (2) minskar auto-increment-contention f\u00f6r parallella INSERTs. F\u00f6r sekvenser eller biljettnummer anv\u00e4nder jag f\u00f6rallokerade block per arbetare s\u00e5 att inte varje allokering l\u00e5ser en central tabell.<\/p>\n\n<p>Valet av nyckel har ocks\u00e5 betydelse: Sammansatta prim\u00e4rnycklar som kartl\u00e4gger den naturliga \u00e5tkomstdimensionen (t.ex. account_id + id) leder till smala, riktade l\u00e5s. Breda UUID:er \u00e4r bra om de \u00e4r slumpm\u00e4ssiga och indexuppdelningar f\u00f6rblir hanterbara.<\/p>\n\n<h2>Batcher, jobbdesign och SKIP LOCKED<\/h2>\n\n<p>Jag planerar bakgrundsjobb i <strong>sm\u00e5 partier<\/strong> (t.ex. 100-500 rader) och anv\u00e4nd stabil sortering via prim\u00e4rnyckeln. I MySQL 8.0 hj\u00e4lper <strong>NU V\u00c4NTA\/HOPPA \u00d6VER L\u00c5ST<\/strong>, f\u00f6r att hoppa \u00f6ver blockerande rader ist\u00e4llet f\u00f6r att ackumulera k\u00f6er. I SQL Server st\u00e4ller jag in <strong>READPAST<\/strong> med <strong>UPDLOCK<\/strong> och <strong>ROWLOCK<\/strong> att g\u00e5 till v\u00e4ga p\u00e5 ett liknande s\u00e4tt.<\/p>\n\n<pre><code>-- MySQL: H\u00e4mta jobb utan blockering\nV\u00c4LJ id FR\u00c5N jobb\n WHERE status = 'redo'\n ORDER BY id\n BEGR\u00c4NSNING 200\n F\u00d6R UPPDATERING HOPPA \u00d6VER L\u00c5ST;\n\n-- SQL Server: Liknande m\u00f6nster\nSELECT TOP (200) id FROM jobs WITH (ROWLOCK, UPDLOCK, READPAST)\n WHERE status = 'redo'\n ORDER BY id;\n<\/code><\/pre>\n\n<p>Jag bryter ner stora, monolitiska underh\u00e5llsk\u00f6rningar i steg som kan \u00e5terupptas. Detta minskar tiden f\u00f6r l\u00e5sning och jobblandskapet f\u00f6rblir robust \u00e4ven n\u00e4r det startas om.<\/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>Migrering och DDL-strategier utan stillest\u00e5nd<\/h2>\n\n<p>Schema\u00e4ndringar kan utl\u00f6sa gigantiska l\u00e5s. I MySQL \u00e4r jag uppm\u00e4rksam p\u00e5 <strong>ALGORITM=INPLACE<\/strong> och <strong>LOCK=INGEN<\/strong>, n\u00e4r det \u00e4r m\u00f6jligt och migrera kolumner i tv\u00e5 steg (skapa ny, fyll, byt). I SQL Server anv\u00e4nder jag <strong>ONLINE=ON<\/strong> (F\u00f6retag) och, om till\u00e4mpligt. <strong>V\u00c4NTA_P\u00c5_L\u00c5G_PRIORITET<\/strong>, s\u00e5 att l\u00e4s-\/skrivtrafiken forts\u00e4tter att k\u00f6ra. Jag timeboxar DDL:er som k\u00f6rs under l\u00e5ng tid, pausar dem vid toppbelastning och \u00e5terupptar dem p\u00e5 ett kontrollerat s\u00e4tt. F\u00f6re varje migrering skapar jag en plan B (rollback-v\u00e4g) och m\u00e4ter de f\u00f6rv\u00e4ntade I\/O-kostnaderna p\u00e5 en kopia.<\/p>\n\n<p>Jag l\u00e4gger till index p\u00e5 ett m\u00e5linriktat s\u00e4tt: f\u00f6rst f\u00f6r frekventa filtervillkor, sedan f\u00f6r JOIN-nycklar. Varje ytterligare index kostar skrivtid - f\u00f6r m\u00e5nga index f\u00f6rl\u00e4nger transaktionerna och \u00f6kar d\u00e4rmed risken f\u00f6r deadlock och minneskrav.<\/p>\n\n<h2>Testning och reproduktion av deadlocks<\/h2>\n\n<p>F\u00f6r fels\u00f6kning bygger jag minimalt <strong>reproducerbar<\/strong> Scenarier med tv\u00e5 sessioner: Session A l\u00e5ser rad X och g\u00e5r sedan in p\u00e5 Y, session B g\u00f6r tv\u00e4rtom. Jag tvingar fram kollisionen med korta SLEEPS mellan satserna. Det \u00e4r s\u00e5 h\u00e4r jag validerar hypoteser fr\u00e5n deadlock-grafen. I MySQL observerar jag PERFORMANCE_SCHEMA (events_transactions_current, data_locks) parallellt, i SQL Server motsvarande ut\u00f6kade events. Jag varierar sedan index, filter och sekvenser tills d\u00f6dl\u00e4get f\u00f6rsvinner.<\/p>\n\n<p>S\u00e5dana tester h\u00f6r hemma i CI: sm\u00e5 belastningstoppar som blandar batchk\u00f6rningar och online-grafik avsl\u00f6jar l\u00e5ssekvensfel tidigt. Viktigt: anv\u00e4nd samma pool- och timeout-v\u00e4rden som i produktionen, annars missar du det verkliga problemet.<\/p>\n\n<h2>Observerbarhet och varning: fr\u00e5n signal till handling<\/h2>\n\n<p>Jag leder n\u00e5gra f\u00e5, tydliga <strong>Signaler<\/strong> fr\u00e5n: Deadlocks\/minut, v\u00e4ntetid f\u00f6r l\u00e5s P95\/P99, procentandel omprovade transaktioner och commit duration P95. Jag utl\u00f6ser varningar n\u00e4r m\u00e4tv\u00e4rdena \u00f6kar under en tidsperiod (t.ex. &gt;5 deadlocks\/min under 10 minuter) och med sammanhang: vilka tabeller, vilka fr\u00e5gor, vilka distributioner som k\u00f6rdes. Jag separerar instrumentpaneler enligt l\u00e4s-\/skrivv\u00e4gar; v\u00e4rmekartor visar n\u00e4r de flesta konflikter uppst\u00e5r (tid, batchf\u00f6nster).<\/p>\n\n<p>F\u00f6r den omedelbara \u00e5tg\u00e4rden definierar jag <strong>Runb\u00f6cker<\/strong>Minska poolgr\u00e4nserna, pausa felaktiga batchjobb, \u00f6ka tillf\u00e4lligt cache TTL, flytta l\u00e4sbelastningen till repliker, j\u00e4mna ut skrivf\u00f6nster. Detta f\u00f6ljs av arbetet med grundorsaken: l\u00e4gg till index, bygg om fr\u00e5gan, desarmera datamodellen, justera isoleringsniv\u00e5n.<\/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>Kort och tydligt: S\u00e5 h\u00e4r h\u00e5ller jag deadlocks p\u00e5 en l\u00e5g niv\u00e5<\/h2>\n\n<p>Jag prioriterar korta <strong>Transaktioner<\/strong>, konsekventa l\u00e5ssekvenser och l\u00e4mpliga isoleringsniv\u00e5er s\u00e5 att l\u00e5sen snabbt sl\u00e4pps igen. Rena index och smidiga fr\u00e5gor minskar varaktigheten f\u00f6r varje kritisk fas. Cacher och l\u00e4srepliker minskar belastningen p\u00e5 den prim\u00e4ra databasen om jag h\u00e5ller ett \u00f6ga p\u00e5 replikeringsf\u00f6rseningar. Connection pooling, timeouts och en retry-logik med backoff s\u00e4kerst\u00e4ller att enskilda konflikter inte avbryter fl\u00f6det. Kontinuerlig \u00f6vervakning med deadlockgraf, P95 och lock waiting visar avvikelser tidigt s\u00e5 att jag kan vidta mot\u00e5tg\u00e4rder innan anv\u00e4ndarna m\u00e4rker n\u00e5got.<\/p>","protected":false},"excerpt":{"rendered":"<p>Omfattande guide till uppt\u00e4ckt av mysql-d\u00f6dl\u00e4ge och problem med databasl\u00e5sning i hosting. Strategier, diagnos och hantering f\u00f6r stabila databaser.<\/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\/sv\/wp-json\/wp\/v2\/posts\/18889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=18889"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/18889\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/18882"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=18889"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=18889"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=18889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}