for update lock 걸었을 때, data_locks row 확인

Question

CREATE TABLE test( id int NOT NULL AUTO_INCREMENT, PRIMARY KEY (id));INSERT INTO test VALUES (3),(5),(7),(9),(11);ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ아래 2개의 트랜잭션을 실행했을 때, data_locks에 대해 이해가 안가는 부분이 있습니다 .자료를 찾아봐도 개념적인 설명만 있고, 실제 lock이 걸렸을 때 data_locks을 보는 방법은 찾기가 힘들더라구요.begin ; SELECT * FROM test WHERE id BETWEEN 5 AND 7 FOR UPDATE;쿼리의 조건과 데이터를 pk로 찾을 수 있기 때문에 record lock인건 알겠는데, 5는 X, REC_NOT_GAP이 걸려있는데 7은 왜 ㅌ락만 걸려 있나요 ?begin ; SELECT * FROM test WHERE id BETWEEN 4 AND 8 FOR UPDATE;4, 8은 데이터가 없기 때문에 범위 검색을 하였고, X, GAP이기 때문에 next key lock인 건 알겠는데, 왜 9만 next key lock으로 표시되어 있고, 5, 7은 X락으로 표시되어 있나요 ? 그냥 대표로 9만 표시를 한건가요 ?begin ; SELECT * FROM test WHERE id > 4 for update next key lock 생긴것을 보여주는 것 같은데, 어떤 부분을 보고 next key lock이 생성된지 정확히 모르겠습니다.

kyuho · Answer

MySQL Lock에 대해 정확한 이해는 아래 내용 참고해보세요.LOCK_MODE 값의 모호한 부분의 이해를 시작으로 하나씩 살펴보시면 도움이 되실 것 같아요. https://dev.mysql.com/blog-archive/innodb-data-locking-part-2-locks/S,REC_NOT_GAP → shared access to the record itselfX,REC_NOT_GAP → exclusive access to the record itselfS,GAP → right to prevent anyone from inserting anything into the gap before the rowX,GAP → same as above. Yes, “S” and “X” are short for “shared” and “exclusive”, but given that the semantic of this access right is to “prevent insert from happening” several threads can all agree to prevent the same thing without any conflict, thus currently InnoDB treats S,GAP and X,GAP (or *,GAP locks, for short) the same way: as conflicting just with *,INSERT_INTENTIONS → is like a combination of S,REC_NOT_GAP and S,GAP at the same time. So it is a shared access right to the row, and prevents insert before it.X → is like a combination of X,REC_NOT_GAP and X,GAP at the same time. So it is an exclusive access right to the row, and prevents insert before it.X,GAP,INSERT_INTENTION → right to insert a new row into the gap before this row. Despite “X” in its name it is actually compatible with others threads trying to insert at the same time.X,INSERT_INTENTION → conceptually same as above, but only happens for the “supremum pseudo-record” whi

for update lock 걸었을 때, data_locks row 확인

1개의 답변

Q&A 목록