Тупик в MySQL анализ
Как да разберем причината за задънена улица - а именно, кои транзакции са заловили кои заключения?
Има файл engine.log със следното блокиране:
Моето виждане за описаното в дневниците:
1. Транзакция # 2 първоначално има едно заключване (докато от регистрационните файлове не става ясно какъв тип е):
*** (2) ЗАДЪРЖА ЗАКЛЮЧВАНЕТО
ЗАПИСИ ЗАКЛЮЧВАНЕ Идентификатор на пространството 0 страница № 36025889 n бита 96 индекс ПРИМАРЕН на таблицата mydb. mytable trx id 4 2719072205 lock_mode X заключва rec, но не празнина
Заключване на запис, куп № 27 ФИЗИЧЕН ЗАПИС: n_fields 72; компактен формат; информационни битове 0
и работата продължава;
2. Транзакция # 1 се опитва да придобие ключалка от тип S:
*** (1) В ОЧАКВАНЕ НА ТОЗИ ЗАКЛЮЧВАНЕ:
ЗАПИСИ ЗАКЛЮЧВАНЕ. trx id 4 2719072253 режим на заключване S заключва запис, но не изчакване на пролука
и започва да чака Транзакция # 2 да освободи заключването си;
3. Транзакция # 2 се опитва да придобие ключалка от тип X:
*** (2) В ОЧАКВАНЕ НА ТОЗИ ЗАКЛЮЧВАНЕ:
ЗАПИСИ ЗАКЛЮЧВАНЕ. trx id 4 2719072205 lock_mode X заключва rec, но не чака изчакване
и започва да чака Транзакция # 1, за да придобие ключалка от тип S и да я освободи.
Разбирам ли правилно дневниците или моята интерпретация е грешна?
И тъй като, съдейки по документацията:
Ако транзакция T1 съдържа споделена (S) ключалка на ред r, тогава заявките от някаква отделна транзакция T2 за заключване на ред r се обработват, както следва:
- Искане от T2 за заключване S може да бъде предоставено незабавно. В резултат на това и T1, и T2 държат S заключване на r.
- Искане от Т2 за заключване X не може да бъде предоставено незабавно.
ако една транзакция притежава ключалка от тип S на ред r, тогава друга транзакция може да придобие тази ключалка S, се оказва, че транзакция # 2 първоначално е имала ключалка X? Но тогава възниква нов въпрос: защо втората транзакция трябва да чака да придобие заключване X (стъпка 3), ако вече го има (от стъпка 1)?