첫째, 스토리지 엔진
우리의 마지막 축제가 온다에서 SQL의 실행 계획을 완료하는 액추에이터 조립 스토리지 엔진 인터페이스 호출입니다.
MySQL의 데이터베이스 관리 시스템은 디스크 파일 스토리지 엔진과 상호 작용하는 데이터의 저장에 의존 : 그런 다음 우리는 이해 될 수있다.
MySQL의 스토리지 엔진은 그래서 무엇 있는가?
등등이의 MyISAM, InnoDB의, 메모리, 그리고. 이제 기본적으로 InnoDB 스토리지 엔진을 사용하여 인터넷, 그럼 간략 InnoDB 스토리지 엔진에 대한 학습, InnoDB 스토리지 엔진 내부의 구성 요소에 상대적으로 간단한 설명을 요약 한 것입니다.
둘째, 버퍼 풀
우리는 지금 데이터베이스에있는 데이터가 디스크 파일에 저장되어있는 것을 알고있다.
그래서 때마다 우리는 테이블에 추가 및 삭제가 내부 디스크 파일 작업에 직접적으로 검색을 변경?
답 : 아니오!
모든 작업은 디스크에서 수행하는 경우 임의 읽기 및 쓰기 디스크 파일의 성능이 매우 가난하기 때문에, 다음 고성능 MySQL의 문이있을 것입니다, MySQL은 높은 동시성을 지원하지 수, 그것은 인터넷에 그렇게되지 않을 것 인기.
이 시간이 InnoDB 스토리지 엔진의 가장 중요한 구성 요소를 소개하고 缓冲池（Buffer Pool）, 그것은 매우 중요한 메모리 구조이다. MySQL이 높은 동시성을 지원할 수 있도록 매우 높은 성능을 읽기 및 쓰기 메모리는 메모리 내부입니다.
풀 (버퍼 풀) 원칙을 사용하여 :
하자의 검토 과정 MySQL의 요청을 받았습니다.
①, 데이터베이스 연결 풀에 MySQL의 모니터 작업자 스레드 전용 연결, 연결은 SQL 문에서 연결을 얻을 수 있습니다.
② 다음 SQL 문 SQL 接口을 처리 할 수는 SQL 인터페이스는 프로세스의 다음 시리즈에서 수행됩니다.
③, 查询解析器뭔가 MySQL의로 해석하는 SQL 문을 이해할 수있다.
④ 다음 查询优化器SQL 문에 대한 최적의 실행 계획의 세트를 개발.
⑤, 执行器이 계획에 따라 실행 스토리지 엔진 인터페이스 호출로 이동합니다.
위의 기사는 일의 요약, 어떻게 CRUD가 수행 할 수있는 스토리지 엔진 인터페이스입니다? 예를 들어 작업을 업데이트하려면, 같은 방법으로 다른.
는 SQL은 행에 대응하는 것인지 우선, 스토리지 엔진 업데이트 먼저 결정할 缓冲池（Buffer Pool）내부. 직접의 단어 경우 缓冲池（Buffer Pool）반환 다음의 데이터를 업데이트하고는,하지 않을 경우, 데이터를 디스크 파일에서 읽은 缓冲池（Buffer Pool）다음 작업을 업데이트 한 다음 결과를 반환합니다.
세, 실행 취소 로그 파일
우리는 트랜잭션이 롤백 트랜잭션에서, 이전까지의 데이터에 대한 업데이트를 제출하는 모든 노하우. 그래서 할 그것에 의존하는 것입니다?
그것은에 의존한다 undo 日志文件.
로그 파일을 취소 원리를 사용 :
데이터 업데이트 예 :
사용자가 데이터 행 ID = (100)를 업데이트 할 경우 원래 열 이름 "홍길동"에서 "홍길동", 다음 시간 것 "ID = 10"와 "이름 = 조 스미스" 두 가지 핵심 메시지를 작성 undo 日志文件한다.
당신이 전에 트랜잭션 커밋 from'll 롤 다시해야 할 때 undo 日志文件이 키워드를 찾은 다음 업데이트 작업을 롤백.
四, 리두 로그 버퍼
그 위에 올 때, CRUD 작업의 모든 실제로 그렇게 실제로 데이터의 변형이 일어나지 않는다, 수영장 내에서 수행 디스크 파일 내부에 즉시 구현합니다.
그런 다음 문제가있는 것입니다 : 디스크 브러시 파일 다시 전에 더티 데이터 버퍼 풀, MySQL은 어떻게 할 아래로 무엇입니까?
이때 이노 스토리지 엔진은 매우 중요한 요소를 제공시, 그 redo log buffer구성 요소. 또한 버퍼의 메모리이다.
원리를 사용하여 버퍼 로그를 다시 실행 :
또는 예로서, 상기 갱신 동작에서 데이터가 업데이트 될 때, 데이터는 키 정보가 대응하는 재실행 로그의 기입되어 갱신되어 기록 redo log buffer된다.
그것은 정상에 온다, 그러나 여전히 문제가있을 것 redo log buffer뿐만 아니라 메모리에. 그 MySQL은 더티 데이터 및 풀 수 있도록 모든 데이터 메모리가 손실되기 때문에, 아래 경우 redo log buffer로그가 여전히 손실됩니다.
이 상황에서, 클라이언트는 정보의 성공적인 갱신을 수신했지만 결국 데이터베이스 내부의 데이터가 성공적으로 업데이트되지 않습니다 발생합니다.
그래서, redo log buffer브러시 세트 전략이있다. 일반적으로, 트랜잭션이 커밋 될 때이 될 것입니다 redo log buffer에 redo 日志너무 걱정하지 마세요, 디스크에 브러시 다시, 트랜잭션이 성공적으로 커밋하지만, 데이터가 손실 업데이트 문제 일 수 있습니다. 심지어에서 缓冲池（Buffer Pool）디스크 브러시 더러운 데이터 다시 앞에, MySQL은 그것은 디스크는 MySQL의 재시작 잃게 데이터를 기반으로 할 수 없기 때문에, 아래로 때 redo 日志모든 더러운 데이터를 복원하기 전에 업데이트합니다.