잠금 문제
13.1 잠금 대기 상태 가져오기
table_locks_waited 및 table_locks_immediate 상태 변수를 확인하여 시스템의 테이블 잠금 경합을 분석할 수 있습니다.
mysql> show status like 'Table%';
+ -------------+----------+
| 변수명 |
+---------------+------------+
| Table_locks_immediate | 105 |
| Table_locks_waited 3 |
+---------------+------ -- -+
2행 세트(0.00초)
Innodb_row_lock 상태 변수를 확인하여 시스템의 행 잠금 경합을 분석할 수 있습니다.
mysql> show status like 'innodb_row_lock%';
+ ---------------+------- -- -+
| 변수_이름 |
+--------------------------------- --------- ----+---------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | |
| Innodb_row_lock_time_max |
| Innodb_row_lock_waits |
+------------- ----------- +----------+
5행 세트(0.00초)
또한 Innodb 유형 테이블의 경우 확인해야 할 경우 현재 잠금 대기 상태를 확인하려면 InnoDB 모니터를 설정한 다음 Show innodb status View를 사용할 수 있습니다. 설정 방법은 다음과 같습니다.
CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
모니터는 다음을 실행하여 중지할 수 있습니다. 다음 명령문:
DROP TABLE innodb_monitor;
모니터링 설정 서버를 설치한 후 show innodb status의 표시 내용에 테이블 이름, 잠금 유형, 잠금 기록을 포함하여 현재 잠금 대기에 대한 자세한 정보가 표시됩니다. 상태 등을 분석하여 추가 분석 및 문제 결정을 용이하게 합니다. 모니터를 연 후에는 기본적으로 15초마다 모니터링 내용이 로그에 기록되는데, 장시간 열어두면 .err 파일의 용량이 매우 커지므로 문제의 원인을 확인한 후 안내해 드리겠습니다. 모니터를 닫으려면 모니터링 테이블을 삭제해야 합니다. 또는 로그 파일 쓰기를 끄려면 --console 옵션으로 서버를 시작하십시오.
13.2 테이블 잠금을 사용하는 경우
다음 상황에서는 테이블 수준 잠금이 행 수준 잠금보다 우수합니다.
1. 많은 작업이 테이블 읽기입니다.
2. 별도의 인덱스를 사용하여 업데이트 또는 삭제를 읽을 수 있는 경우 엄격한 조건부 인덱스에 대한 읽기 및 업데이트:
3. UPDATE tbl_name SET 열=값 WHERE Unique_key_col=key_value;
4. tbl_name에서 삭제 WHERE Unique_key_col=key_value;
5. SELECT 및 INSERT 문이 동시에 실행되지만 UPDATE 및 DELETE 문이 몇 개만 있습니다.
6. 전체 테이블에 대한 많은 테이블 스캔 및 GROUP BY 작업이 수행되지만 테이블 쓰기는 수행되지 않습니다.
13.3 행 잠금을 사용하는 경우 행 수준 잠금의 장점:
1. 여러 스레드에서 서로 다른 행에 액세스할 때 잠금 충돌이 거의 발생하지 않습니다.
2. 롤백 시 작은 변경 사항만 적용됩니다.
3. 단일 행을 오랫동안 잠글 수 있습니다.
행 수준 잠금의 단점:
1. 페이지 수준 또는 테이블 수준 잠금보다 메모리를 더 많이 차지합니다.
2. 테이블의 큰 부분에 사용할 경우 더 많은 잠금을 획득해야 하므로 페이지 수준 또는 테이블 수준 잠금보다 느립니다.
3. 대부분의 데이터에 대해 GROUP BY 작업을 자주 수행하거나 전체 테이블을 자주 스캔해야 하는 경우 다른 잠금보다 속도가 상당히 느려집니다.
4. 다양한 유형의 잠금을 지원하여 행 수준 잠금보다 잠금 비용이 저렴하므로 애플리케이션을 쉽게 조정할 수 있습니다.