Transakcioni storage-engine-i sa zaključavanjem na nivou sloga. specijalno oni integrisani u SQL server su prirodno skloni deadlock-ovima. Kako su isti „smrt za performanse“ bitno je unapred planirati način na koji će se taj problem rešiti ili zaobići.
InnoDB, transakcioni storage engine, deo MySQL-a ima algoritam za detekciju deadlock situacije koji funkcioniše tako da kada postavlja novi lock, InnoDB proveri da li će to proizvesti deadlock situaciju ili ne. U slučaju da se deadlock situacija detektuje, problematična transakcija će se poništiti (roll back). U sistemu kao sto je MySQL gde InnoDB nije jedini storage engine, InnoDB nije u stanju da detektuje svaku deadlock situaciju, pošto je InnoDB svestan samo lokova koji se nalaze unutar (pod kontrolom) InnoDB-a i u slučaju da deadlock situacija nije detektovana na takav način, InnoDB koristi dodatni sistem za detekciju deadlock situacije zasnovanu na time-out-u. Taj time-out se kontroliše sistemskom varijablom innodb_lock_wait_timeout.
Dodatna stvar o kojoj se mora voditi računa su „table locks“. MySQL daje mogućnost korisniku da lokuje celu tabelu (LOCK TABLES). InnoDB je svestan ovih lokova kroz innodb_table_locks. Kada je ova varijabla 1 InnoDB uzima interni storage-engine-level lock nad tabelom u slučaju kada je LOCK TABLES pozvan. Kada gledamo veću sliku i obratimo pažnju na ostale storage engine, cross storage engine deadlocks postaju realnost. InnoDB sistem zasnovan na timeout-u može se koristiti za rešavanje tog problema.
Cilj dobrog DB administratorra i DB developera je da izbegne deadlock situacije pravilnim dizajnom baze i pravilnim dizajnom upita. Ceo MySQL-ov sistem za izbegavanje deadlock situacije je samo dodatna zaštita, dok pravilno napravljen sistem ne bi trebalo da se ikad nađe u takvoj situaciji.