업데이트를 위한 mysql 동시성 플러스가 잠겨 있지 않습니다.

트랜잭션이 길어요
가운데와 뒷부분에 행 단위 잠금 장치가 있습니다
테스트 결과 잠겨 있지 않은 것으로 확인되었습니다
이 부분을 떼어내면 별도로 잠길 수 있습니다.
긴 거래 전체에서 어떤 상황에서 잠금에 영향을 미치나요?
업데이트하려면 product_term에서 ID를 선택하세요. 여기서 Id=".$v['P_Term_id']."

답글 내용:

트랜잭션이 길어요

가운데와 뒷부분에 행 단위 잠금 장치가 있습니다
테스트 결과 잠겨 있지 않은 것으로 확인되었습니다
이 부분을 떼어내면 별도로 잠길 수 있습니다.
긴 거래 전체에서 어떤 상황에서 잠금에 영향을 미치나요?
업데이트하려면 product_term에서 ID를 선택하세요. 여기서 Id=".$v['P_Term_id']."

설정이 영향을 받습니다.

사실요. . 먼저 초보 질문 하나 드리겠습니다. . . 이노드인가요? 예전에 마이삼의 일에 대한 질문을 접한 적이 있습니다. .

알겠습니다. 주제로 돌아갑니다.
배타적 잠금은 일반적으로 트랜잭션이 끝날 때까지 이 쿼리 범위를 잠급니다.
당신과 똑같습니다. ID 행에 해당하는 레코드가 잠깁니다.
그러나 거래의 격리 모드에 따라 다릅니다. 설정을 변경하지 않은 경우 기본값은 RR입니다. 즉, 이 배타적 잠금 이전에 실행한 SELECT의 결과는 동일합니다. . 이렇게 하면 잠겨 있지 않은 것 같은 착각이 들게 됩니다. .

당신의 사업이 이렇다면

이와 같이 기본 RR 수준으로 인해 첫 번째 범위 검색에는 이미 id=1이 포함되어 있으며 동일한 트랜잭션에서 얻은 세 번째 행은 첫 번째 행과 동일합니다. 실제로 이 행의 데이터는 두 번째 행에서 변경되었습니다. 동시성이 2개일 경우 테이블이 잠겨있지 않은 것처럼 보일 수도 있습니다~~

<code>BEGIN;
SELECT id FROM product_term where id<100;
UPDATE product_term SET XXX='YYY' WHERE id = 1;
...
SELECT id FROM product_term where id=1 FOR UPDATE;
...
COMMIT;</code>

트랜잭션 시작시에만 하는 것을 권장합니다.

이 문제가 발생하는지 모르겠습니다. 그렇다면 트랜잭션 격리 모드를 주의 깊게 연구해 보면 함정이 더 많다는 것을 알게 될 것입니다