För det första är dödlägen inte beroende av explicit låsning. MySQL:s LOCK TABLE eller användning av icke-standardiserade transaktionsisoleringslägen krävs INTE för att ha ett dödläge. Du kan fortfarande ha dödlägen om du aldrig använder en explicit transaktion.
Deadlocks kan hända på ett enda bord, ganska enkelt. Oftast är det från ett enda varmt bord.
Dödläge kan till och med hända om alla dina transaktioner bara infogar en enda rad.
Ett dödläge kan hända om du har
- Mer än en anslutning till databasen (uppenbarligen)
- All verksamhet som internt involverar mer än ett lås.
Vad som inte är uppenbart är att en rad infogning eller uppdatering oftast involverar mer än ett lås. Anledningen till detta är att sekundära index också måste låsas under infogning/uppdateringar.
SELECTs låses inte (förutsatt att du använder standardisoleringsläget och inte använder FÖR UPPDATERING) så de kan inte vara orsaken.
VISA MOTOR INNODB STATUS är din vän. Det kommer att ge dig en massa (visserligen mycket förvirrande) information om dödlägen, närmare bestämt den senaste.
- Du kan inte helt eliminera dödlägen, de kommer att fortsätta att hända i produktionen (även på testsystem om de stressas ordentligt)
- Sikta efter ett mycket litet antal dödlägen. Om 1 % av dina transaktioner låser sig är det möjligen för många.
- Överväg att ändra transaktionsisoleringsnivån för dina transaktioner till read-committed OM DU HELT FÖRSTÅR KONSEKVENSERNA
- se till att din programvara hanterar dödlägen på rätt sätt.