MySQL 트랜잭션 격리에 대한 간략한 토론-MySQL 튜토리얼-php.cn

MySQL 트랜잭션 격리에 대한 간략한 토론

青灯夜游

풀어 주다： 2020-04-04 09:29:51

앞으로

1968명이 탐색했습니다.

이 문서에서는 MySQL 트랜잭션 격리에 대해 설명합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.

MySQL 트랜잭션 격리에 대한 간략한 토론

트랜잭션 소개

트랜잭션은 원자성 SQL 쿼리 집합 또는 독립적인 작업 단위입니다. 즉, 트랜잭션 내의 명령문은 모두 성공적으로 실행되거나 모두 실패합니다.

Mysql에서는 트랜잭션 지원이 엔진 계층에서 구현되지만 모든 Mysql 엔진이 트랜잭션을 지원하는 것은 아닙니다. 예를 들어 MyISAM 엔진은 트랜잭션을 지원하지 않습니다. 이것이 MyISAM이 InnoDB로 대체된 중요한 이유 중 하나입니다.

트랜잭션에 있어서 우리는 반드시 ACID를 생각할 것입니다:

원자성
일관성
격리
내구성

격리 수준

다중 거래 시 데이터베이스에서 동시에 실행되는 경우 트랜잭션 격리 수준 개념으로 인해 더티 읽기(Dirty Read), 반복 불가능 읽기, 팬텀 읽기(Phantom Read) 등의 문제가 발생할 수 있습니다.

SQL 표준은 네 가지 격리 수준을 정의합니다.

READ UNCOMMITTED(커밋되지 않은 읽기)

트랜잭션의 수정 사항은 커밋되지 않았더라도 다른 트랜잭션에서 볼 수 있습니다. 트랜잭션은 더티 읽기라고도 하는 커밋되지 않은 데이터를 읽을 수 있습니다.
READ COMMITTED

거래가 제출된 후 변경 사항은 다른 거래에서 볼 수 있습니다. 이 수준은 반복 불가능 읽기라고도 합니다. 트랜잭션에서 동일한 쿼리가 두 번 실행되면 결과가 다를 수 있기 때문입니다.
REPEATABLE READ(반복 읽기)

트랜잭션 실행 중에는 트랜잭션이 시작될 때 표시되는 데이터와 항상 일치합니다. 물론 이 수준에서는 커밋되지 않은 데이터 변경 사항도 다른 트랜잭션에서 볼 수 없습니다.
SERIALIZABLE(직렬화 가능)

동일한 레코드 행에 대해 읽기-쓰기 잠금 충돌이 발생하면 나중에 액세스하는 트랜잭션은 이전 트랜잭션의 실행이 완료될 때까지 기다려야 합니다. 계속 실행되면 많은 시간 초과 및 잠금 경합 문제가 발생할 수 있습니다.

구현 측면에서 뷰는 데이터베이스에 생성되며 액세스 시 뷰의 논리가 우선합니다.

반복 읽기 격리 수준에서 이 뷰는 트랜잭션이 시작될 때 생성되며, 이 뷰는 전체 트랜잭션 동안 사용됩니다.

읽기-커밋 격리 수준에서 이 뷰는 SQL 문이 실행되기 시작할 때 생성됩니다.

읽기 커밋되지 않은 격리 수준에서는 뷰 개념 없이 레코드의 최신 값이 직접 반환됩니다.

직렬화된 격리 수준에서는 병렬 액세스를 방지하기 위해 직접 잠급니다.

구성 방법은 시작 매개변수transaction-isolation를 원하는 격리 수준으로 설정하는 것입니다.

현재 설정 보기:

mysql> show variables like &#39;transaction_isolation&#39;;
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)

로그인 후 복사

간단히 말하면, 다양한 격리 수준은 다양한 시나리오에 적합합니다.

트랜잭션 격리 구현

실제로 MySQL에서는 각 레코드의 업데이트도 롤백 작업을 통해 기록됩니다.

롤백해야 할 트랜잭션이 없을 때 시스템은 자동으로 롤백 로그를 삭제한다고 결정합니다.

긴 트랜잭션을 사용하지 않는 것이 좋습니다.

긴 트랜잭션은 시스템에 매우 오래된 트랜잭션 뷰가 있음을 의미합니다. 이러한 트랜잭션은 이 트랜잭션이 제출되기 전에 언제든지 데이터베이스의 모든 데이터에 액세스할 수 있기 때문입니다. 데이터베이스에서 사용될 수 있는 수익을 롤링 기록으로 유지해야 하므로 많은 저장 공간을 차지합니다. 동시에 긴 트랜잭션도 잠금 리소스를 점유하고 전체 라이브러리를 다운시킬 수 있습니다.

트랜잭션을 시작하는 방법

명시적으로 트랜잭션 문을 시작하고, 트랜잭션을 시작하거나 시작하고, 커밋은 커밋이고, 롤백은 롤백입니다.
set autocommit = 0, 이 명령은 스레드의 자동 제출을 해제합니다. 즉, select 문을 실행하면 트랜잭션이 시작되고 커밋이나 롤백을 적극적으로 실행할 때까지 자동으로 제출되지 않습니다. 또는 연결을 엽니다.

개인적으로 제안하는 것은 긴 트랜잭션이 발생하지 않도록 첫 번째 방법을 통해 명시적으로 트랜잭션을 시작하는 것입니다.

autocommit = 1로 설정된 경우 트랜잭션이 명시적으로 시작되면 커밋이 실행되면 트랜잭션이 커밋됩니다. 커밋 작업 및 체인을 실행하면 해당 트랜잭션이 커밋되고 다음 트랜잭션이 자동으로 시작되므로 다시 시작 문을 실행하는 오버헤드도 절약됩니다.

긴 트랜잭션 쿼리:

다음 명령문은 60초 이상 지속되는 트랜잭션을 쿼리하는 것입니다.

mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60;
Empty set (0.00 sec)

로그인 후 복사

요약하자면, 개발 과정에서 피할 수 없는 경우에는 긴 트랜잭션을 최대한 적게 사용하려고 노력합니다. 논리적 로그 공간이 충분히 큰지 확인하고 동적 로그 공간 증가를 지원합니다. Innodb_trx 테이블을 모니터링하고 긴 트랜잭션 경보를 보고합니다.