sql >> Databasteknik >  >> RDS >> Mysql

Deadlock med SELECT ... FÖR UPPDATERING i MySQL

Vad fungerar och vad som inte fungerar

Ett sätt att få båda transaktionerna att gå igenom utan dödläge är att ändra isoleringsnivå till LÄS ENGAGERADE (eller LÄS OENGAGERAD ) i båda anslutningarna:

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

(innan start transaction ).

Förmodligen skulle det räcka att ställa in den i t2 , men för att vara säker på exemplet, ställ in det i båda.

Att ändra isoleringsnivån för transaktioner medför vissa biverkningar, som man bör informera om i manualen innan du ändrar detta i en produktionsmiljö.

Statusinformation om dödläge

------------------------
LATEST DETECTED DEADLOCK
------------------------
140424  8:45:46
*** (1) TRANSACTION:
TRANSACTION B6F18A3, ACTIVE 5 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 13885, OS thread handle 0x7f8b1dbd2700, query id 901012
 localhost root statistics
SELECT * FROM t WHERE id = 1 FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 22921 n bits 72 index `PRIMARY` of table
 `test`.`t` trx id B6F18A3 lock_mode X locks rec but not gap waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000b6f1883; asc    o  ;;
 2: len 7; hex 06000059a211ea; asc    Y   ;;
 3: len 5; hex 48656c6c6f; asc Hello;;

*** (2) TRANSACTION:
TRANSACTION B6F18A2, ACTIVE 10 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 376, 2 row lock(s)
MySQL thread id 13888, OS thread handle 0x7f8b1f64d700, query id 901068
 localhost root Updating
UPDATE t SET `descc` = 'Hello from t1'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 22921 n bits 72 index `PRIMARY` of table
 `test`.`t` trx id B6F18A2 lock_mode X locks rec but not gap
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000b6f1883; asc    o  ;;
 2: len 7; hex 06000059a211ea; asc    Y   ;;
 3: len 5; hex 48656c6c6f; asc Hello;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 22921 n bits 72 index `PRIMARY` of table
 `test`.`t` trx id B6F18A2 lock_mode X waiting
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 00000b6f1883; asc    o  ;;
 2: len 7; hex 06000059a211ea; asc    Y   ;;
 3: len 5; hex 48656c6c6f; asc Hello;;

*** WE ROLL BACK TRANSACTION (1)

Förklaring

Som a_horse_with_no_name nämnde verkar detta som en bugg i MySQL. Transaktion (2) vill få ett gaplås på samma rad som den redan har ett X-lås. Transaktion (1) väntar på ett icke-gap X-lås på denna rad. Det är inte klart för mig varför dessa önskemål skulle komma i konflikt. Ställer in isoleringsnivån till READ COMMITTED inaktiverar spaltlåsning. Eftersom exemplet fungerar då är detta en antydan om att gaplåsning verkligen är problemet här.




  1. Välj högsta 3 poäng varje dag för varje användare

  2. Hur man stryper inloggningsförsök - PHP &MySQL &CodeIgniter

  3. String -> java.util.Date -> java.sql.Date (med tidsstämpel)

  4. Finns det något sätt att definiera en namngiven konstant i en PostgreSQL-fråga?