MySQL의 테이블 잠금과 행 잠금의 차이점은 다음과 같습니다. 1. 테이블 잠금은 Myisam 스토리지 엔진을 선호하고 행 잠금은 Innodb 스토리지 엔진을 선호합니다. 2. 테이블 잠금은 오버헤드가 작은 반면 행 잠금은 오버헤드가 큽니다. 3. 테이블 잠금에는 큰 잠금 세분성이 있습니다. 행 잠금에는 작은 잠금 세분성이 있습니다.
이 글에서는 MySQL의 테이블 잠금과 행 잠금에 대해 자세히 소개하고, 차이점을 분석하고 비교해 보도록 하겠습니다.
(추천 비디오 튜토리얼: mysql 비디오 튜토리얼)
1. 테이블 잠금
특징: 선호하는 MyISAM 스토리지 엔진, 낮은 오버헤드, 빠른 잠금, 큰 잠금 세분성, 잠금 충돌 가능성 없음; 동시성이 가장 낮습니다.
테이블을 편집하거나 테이블을 수정하기 위해 명령문을 실행할 때 일반적으로 일부 비동기 작업을 피하기 위해 테이블 잠금을 추가합니다. 하나는 읽기 잠금이고 하나는 쓰기 잠금입니다.
이 두 잠금을 테이블에 수동으로 추가할 수 있습니다.
lock table 表名 read(write);
모든 테이블의 잠금을 해제합니다.
unlock tables;
잠긴 테이블 보기:
show open tables;
읽기 잠금(공유 잠금) 추가:
테이블에 읽기 잠금을 추가하면 어떤 효과가 있습니까?
1. 읽기 잠금을 추가한 프로세스는 읽기 잠금이 있는 테이블을 읽을 수 있지만 다른 테이블은 읽을 수 없습니다.
2. 읽기 잠금이 설정된 프로세스는 읽기 잠금이 설정된 테이블을 업데이트할 수 없습니다.
3. 다른 프로세스는 읽기 잠긴 테이블을 읽을 수 있고(공유 잠금이기 때문에) 다른 테이블도 읽을 수 있습니다.
4. 읽기 잠긴 테이블을 업데이트하는 다른 프로세스는 대기 상태가 됩니다. 잠금이 해제될 때까지 잠금이 해제된 후에만 업데이트가 성공합니다.
쓰기 잠금(독점 잠금):
1 잠금 프로세스는 잠긴 테이블에서 모든 작업(CURD)을 수행할 수 있습니다.
2. 다른 프로세스는 잠긴 테이블을 쿼리할 수 없으며 잠금이 해제될 때까지 기다려야 합니다.
요약:
읽기 잠금은 쓰기를 차단하지만 읽기를 차단하지는 않습니다. 쓰기 잠금은 읽기와 쓰기를 모두 차단합니다. (프로세스에 특히 주의하세요)
분석:
show status like 'table%';
위 명령을 입력하면 다음을 얻을 수 있습니다.
+----------------------------+----------+ | Variable_name | Value | +----------------------------+----------+ | Table_locks_immediate | 105 | | Table_locks_waited | 3 | +----------------------------+----------+
Table_locks_immediate: 생성된 테이블 수준 잠금 수, 즉시 잠금을 획득할 수 있는 쿼리 수를 나타냅니다. 즉시 획득할 때마다 잠금 값이 1씩 증가합니다.
Table_locks_waited: 테이블 수준 잠금 경합으로 인해 대기가 발생한 횟수(즉시 잠금을 얻을 수 없는 횟수, 대기할 때마다 잠금 값이 1씩 증가함) 심각한 테이블 수준 잠금 경합.
2. 행 잠금
특징: 높은 오버헤드와 느린 잠금으로 인해 InnoDB 스토리지 엔진에 편향되어 있으며 잠금 세분성이 가장 낮고 잠금 충돌 가능성이 가장 낮습니다. 동시성이 가장 높습니다.
Row lock은 트랜잭션을 지원하므로 트랜잭션에 대한 지식은 다음 블로그에 정리하겠습니다.
동작:
1. 행을 업데이트했지만 제출하지 않으면 다른 프로세스도 행 업데이트를 기다려야 합니다.
2. 행을 업데이트하면 다른 행을 업데이트하는 다른 프로세스는 영향을 받지 않습니다.
행 잠금이 테이블 잠금으로 업그레이드됨:
행 잠금에 인덱스 오류가 포함되면 테이블 잠금 동작이 트리거됩니다.
일반적인 상황에서는 서로 영향을 주지 않고 각각 자신의 행을 잠그는데, 하나는 2000이고 다른 하나는 3000입니다.
열 필드 b에 인덱스가 생성되므로 정상적으로 사용하지 않으면 행 잠금이 발생합니다. 테이블 잠금이 되려면
예를 들어 작은따옴표를 추가하지 않으면 인덱스가 실패하고 행 잠금이 테이블 잠금
으로 변경되어 차단되어 대기합니다. Session_1이 제출된 후에야 차단이 해제되고 업데이트가 완료됩니다
그래서 여기서도 여전히 인덱스 쿼리를 잘 활용해야 합니다.
간격 잠금:
동등 조건 대신 범위 조건을 사용하여 데이터를 검색하고 공유 또는 배타적 잠금을 요청하면 InnoDB는 키 값에 대한 조건을 충족하는 기존 데이터 레코드의 인덱스 항목을 잠급니다. 범위 내에 있지만 존재하지 않는 조건 레코드를 "갭"이라고 합니다. InnoDB는 이 "갭"도 잠급니다. 이 잠금 메커니즘은 소위 갭 잠금(Next-Key 잠금)입니다.
Query가 실행 중 범위 검색을 통과하면 해당 키 값이 존재하지 않더라도 전체 범위의 모든 인덱스 키 값을 잠그기 때문입니다.
Gap 잠금에는 치명적인 약점이 있습니다. 즉, 키 값 범위를 잠근 후 존재하지 않는 일부 키 값도 무고하게 잠기므로 잠긴 키 값 범위 내에 데이터를 삽입할 수 없게 됩니다. 모든 데이터. 일부 시나리오에서는 이로 인해 성능이 크게 저하될 수 있습니다.
최적화 제안:
인덱스가 없는 행 잠금이 테이블 잠금으로 업그레이드되는 것을 방지하려면 가능한 한 모든 데이터 검색을 인덱스를 통해 완료하세요.
인덱스를 합리적으로 설계하고 잠금 범위를 최대한 줄이세요
Gap 잠금을 피하기 위해 검색 조건을 최대한 최소화하세요
트랜잭션 크기를 제어하고 잠긴 리소스의 양과 길이를 줄여보세요
낮음- 가능한 한 수준의 거래 격리
위 내용은 MySQL의 테이블 잠금과 행 잠금의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!