MySQL 데이터베이스에서 SQL이 실행되는 방식

오늘은 mysql 동영상 튜토리얼 칼럼을 통해 업데이트 문의 실행 과정을 살펴보겠습니다.

쿼리문과 업데이트문에 대한 일련의 실행 프로세스도 동일한 단계를 거치게 됩니다. 지난 글의 그림을 간단히 살펴보겠습니다.

" class="lazyload" src="https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d529960ec1dd496ca90860641bcaa093~tplv-k3u1fbpfcp-watermark.image" data- style="max-width:90%" data- style="max-width:90%">

우선, 실행 명령문을 작성하기 전에 먼저 데이터베이스에 연결해야 합니다. 이것이 첫 번째 단계에서 커넥터의 작업입니다. 앞에서 말했듯이 테이블이 업데이트되면 이 테이블과 관련된 쿼리 캐시가 무효화됩니다. 일반적으로 10월 쿼리는 권장되지 않습니다.

다음으로 분석기는 이것이 업데이트 문이라는 것을 알게 된 후 어떤 인덱스를 사용할지 결정하고 실행기는 먼저 이 행을 찾은 다음 해당 행을 찾습니다. 업데이트합니다.

쿼리문 업데이트와 다르게 업데이트 프로세스에는 두 가지 중요한 로그도 포함됩니다. 이에 대해서는 이전 기사에서도 소개한 바 있습니다. 관심이 있으시면 지난주 기사 "MySQL의 두 로그 시스템"을 찾아보실 수 있습니다. 여기에 많이 소개해주세요.

간단한 예를 통해 업데이트 작업 과정을 분석해 보겠습니다.

먼저 기본 키 ID와 정수 필드 c:

mysql> create table demo T (ID int primarty ,c int);复制代码

를 사용하여 테이블을 생성합니다.

그런 다음 ID=2인 행의 값에 1을 추가

mysql> update table demo set c = c + 1 where ID = 2;复制代码

다음으로 업데이트의 실행 흐름을 살펴보겠습니다. 명령문에서 그림의 밝은 색 상자는 스토리지 엔진에서 실행되는 것을 나타내고, 색이 있는 상자는 실행기에서 실행되는 것을 나타냅니다.

리두로그 작성은 준비와 커밋의 두 단계로 나누어져 있음을 알 수 있습니다. 이를 흔히 "2단계 커밋"이라고 부릅니다.

로그에 "2단계 제출"이 필요한 이유는 무엇인가요?

redo 로그와 binlog는 각각 스토리지 엔진과 실행기의 로그이므로 두 개의 독립적인 로직이므로 2단계 제출을 사용하지 않으면 어느 것을 먼저 제출하고 어느 것을 나중에 제출하든 문제가 발생합니다. . 위의 예를 살펴보겠습니다. ID=2인 행의 현재 값이 0이라고 가정합니다. 업데이트 프로세스 중에 첫 번째 로그가 기록된 후 두 번째 로그가 기록되기 전에 충돌이 발생합니다.

• 먼저 redolog를 작성한 다음 binlog를 작성하세요. redolog는 작성되었지만 binlog는 아직 작성되지 않아 MySQL 프로세스가 비정상적으로 다시 시작된다고 가정합니다. 우리는 리두로그가 작성된 후 시스템이 충돌하더라도 데이터를 복원할 수 있다는 것을 알고 있으므로 MySQL을 다시 시작한 후에는 이 행이 1로 복원됩니다. binlog가 완료되기 전에 crash가 발생하므로 현재 binlog에는 그러한 문이 없으므로 나중에 로그를 백업할 때 저장된 binlog 로그에는 이 문이 없습니다. binlog를 통해 데이터를 복원해야 하는 경우 binlog에서 이 명령문이 손실되었기 때문에 복원된 행의 값은 0이 되며 이는 원본 데이터베이스의 값과 다릅니다.
• binlog를 먼저 작성한 다음 로그를 다시 실행하세요. 버그로그를 작성한 후 redo 로그가 완료되기 전에 충돌이 발생하고 이때 데이터베이스에 충돌이 발생하면 복구 후 트랜잭션이 무효화되므로 이 줄의 값은 여전히 ​​0이지만 업데이트 문이 기록되었습니다. binlog.log에서 나중에 데이터를 복원하기 위해 binlog를 사용해야 할 경우 이 업데이트 문을 실행하여 값을 원래 데이터베이스의 0과 다른 0에서 1로 업데이트합니다.

"2단계 커밋"을 사용하지 않으면 데이터베이스 상태가 로그를 사용하여 복원된 데이터베이스와 일치하지 않는 것을 볼 수 있습니다. 데이터를 복구하기 위해 로그를 사용할 가능성은 상대적으로 낮지만, 로그의 가장 일반적인 사용은 전체 백업 및 binlog를 통해 달성되는 용량 확장 중입니다. 이로 인해 온라인 마스터-슬레이브 데이터베이스 간의 불일치가 발생할 수 있습니다.

관련 무료 학습 권장사항: mysql 비디오 튜토리얼

위 내용은 MySQL 데이터베이스에서 SQL이 실행되는 방식의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!