이유:
다중 SQL 세션의 경우 리소스 경쟁으로 인해 양 당사자가 잠금 해제를 기다리고 있으며 이때 교착 상태가 발생합니다.
mysql 잠금 유형:
공유 잠금, 읽기 잠금, S 잠금: 여러 트랜잭션이 동일한 데이터에 대한 잠금을 공유할 수 있으며 읽기만 가능하고 쓰기는 불가능합니다.
독점 잠금, 쓰기 잠금, X 잠금: 동시에 하나의 트랜잭션만 얻을 수 있으며 데이터가 잠겨 있으면 다른 트랜잭션에서 수정할 수 없습니다.
의도 잠금 ix는
트랜잭션 A가 사용자 테이블의 레코드 r을 수정하고 레코드 r에 행 수준 배타적 잠금(X)을 부여하는 동시에 사용자 테이블에 의도 배타적 잠금(IX)을 부여합니다. 이때 트랜잭션 B는
사용자 테이블에 대한 A 테이블 수준 배타적 잠금을 차단합니다. 이러한 방식으로 의도 잠금은 행 잠금과 테이블 잠금의 공존을 실현하고 트랜잭션 격리 요구 사항을 충족합니다.
예:
t1:
트랜잭션 시작;
업데이트를 위해 id=30인 fenqu에서 *를 선택합니다.
업데이트 테스트 세트 코드=30 여기서 id=31;
t2:
트랜잭션 시작;
업데이트를 위해 id=31인 fenqu에서 *를 선택합니다.
업데이트 테스트 세트 코드=31 여기서 id=30;
t1은 30을 잠근 후 31을 수정하고, t2는 31을 잠근 후 30을 수정합니다. 이때
30과 31은 모두 배타적 잠금으로 설정되어 있기 때문에 상대방이 해제하기를 기다리게 되어 교착 상태가 형성됩니다.
빠른 문제 해결 계획:
옵션 1:
테이블 쿼리
mysql 자체 라이브러리 INFORMATION_SCHEMA에는 잠금에 대한 두 개의 테이블이 있습니다.
INNODB_LOCKS: InnoDB 트랜잭션이 요청했지만 아직 획득하지 않은 각 잠금과 다른 트랜잭션을 방지하는 트랜잭션이 보유한 각 잠금에 대한 정보를 제공합니다.
INNODB_LOCK_WAITS: 차단된 각 InnoDB 트랜잭션에 대해 요청한 잠금 및 해당 요청을 차단하는 잠금을 나타내는 하나 이상의 행을 포함합니다.
INFORMATION_SCHEMA.INNODB_LOCKS에서 * 선택;
거래 ID 249187이 ID 249119의 잠금으로 차단됨
옵션 II:
로그 쿼리
엔진 INNODB 상태 표시;
세 번째 솔루션:
Alibaba Cloud 서비스를 사용하는 경우
DAS용 ApsaraDB -> 인스턴스 선택 -> 실시간 성능 -> 분석 잠그기 -> 즉시 진단;