; MySQL의 기본 스토리지 엔진은 'storage_engine'와 같은 명령 SHOW 변수를 사용하여, 이노 인
A, InnoDB 스토리지 엔진
트랜잭션 데이터베이스 엔진 1.InnoDB 선택, 안전한 트랜잭션 테이블 (산)에 대한 지원
거래 지원되지 않습니다 : (의 MyISAM은 만 지원 테이블 수준 잠금 )
트랜잭션의 ACID 속성 : 즉 원 자성, 일관성, 격리, 영속성
자성 : 자성이 문 세트 중 하나를 모든 트랜잭션이 절반 오류로 실행하면, 모든 실행 실행 여부 데이터베이스는 다시 현지 업무의 구현의 시작 부분으로 롤백해야합니다.
구현 : 주로 기반 리두 MySQ 시스템 로그와 메커니즘을 취소. 트랜잭션은 SQL 문의 집합입니다, 쿼리 기능을 선택 삭제할 수 있습니다. 각 문은 노드가있을 것입니다. 예를 들어, DELETE 문이 실행되는 트랜잭션에 보존 레코드가, 우리가 뭔가를 수행 한 기록을 저장. 오류가 발생하면, 그것은 다시 원래 위치로 롤 것입니다 뭔가를했던 내부에 저장되어 다시 실행 한 다음 역을 다시 실행합니다.
B 일관성 : 시작과 트랜잭션의 끝, 데이터베이스의 무결성 제약 조건은 이전에 손상되지 않습니다. (EG는 B에 전송하는 바와 같이, 비용이 버클 수 없으며, B가 수신되지 않은)
C를 격리 : 동일한 시간, 동일한 데이터에 대해 하나 개의 트랜잭션 요청을 다른 트랜잭션들 사이에서 서로 간섭하지 않고 ;.
아니라면 고립은 몇 가지 질문이 발생 고려할 것입니다 :
난 더티 판독 확약 다른 트랜잭션 (판독 데이터의 트랜잭션 처리를 참조하는 트랜잭션 데이터가 여러 번 변경되는 있지만 트랜잭션이 많은 시간이 아직 변형되지 않은 때 (얼룩 다른 트랜잭션을 커밋 판독) 상기 거래 데이터에 동시에 액세스하는 경우에 제출 트랜잭션 두 획득 일관성 데이터)를 발생한다
데이터베이스 속 : II, 반복 불가능한 읽기 (이전 트랜잭션 데이터를 제출 된 쿼리를 판독 동일하다 데이터 트랜잭션의 범위 내에서 다수의 쿼리는 쿼리 간격에 기인 한 전송 다른 트랜잭션에 의해 수정되어, 서로 다른 데이터 값을 반환했다 데이터 항목)
III, 팬텀 읽어 만든 모든 라인의 테이블에있어서의 데이터 항목의 트랜잭션 T1 "1" "2"로 동작 : 언제 비 독립적 인 트랜잭션 실행 (EG 발생하는 현상 트랜잭션 T2 및 시간 T1, 사용자는, 우리가 데이터 테이블 행은 데이터 항목에 삽입 수정할 수 있는지 확인하기 위해 트랜잭션을 운영하면서 데이터 항목 또는 "1", 데이터베이스에 제출하는 값, (), 이전 트랜잭션 데이터가 제출 된 전체 데이터의 배치를 읽어, 우리는 선이) 사실,이 라인은 같은 환각처럼, 트랜잭션 T2에서 추가, 수정하지가 있음을 발견
지속성 D : 트랜잭션이 완료된 후 데이터베이스 트랜잭션에 대한 모든 업데이트가 데이터베이스에 저장됩니다, 당신은 롤백 할 수 없습니다
2.InnoDB MySQL의 기본 스토리지 엔진, 기본 다중 버전 동시성 제어를 통해 격리 수준 RR, 그리고 가까이 RR 격리 수준에서 한 단계, (이다 MVCC)은 즉, 가상의 문제점을 해결하기 동시성 제어) 판독 (비 반복 읽기의 문제 더하여 간극 로크를 해결한다. 동시 좋은 성능을 유지하면서 따라서 이노의 RR 분리 레벨은 실제로 효과 직렬화 레벨을 달성한다.
네 개의 분리 MySQL 데이터베이스의 수준을 우리에게 제공합니다 :
A, 직렬화 (직렬화), 더티 읽기 반복 불가능한 읽기를 방지 할 수 있습니다, 팬텀 읽기가 발생합니다 (직렬화에 큰 영향 쿼리의 효율성을 사용하지 않음)
B, 반복 읽기 (반복 읽기) : 수 (기본 분리 레벨) 피 더러운 비 반복 발생 판독 판독
발생 판독 오염을 피할 수있다 : C, 커밋 읽기 (커미트 읽기)
D, 판독 커밋 (확약 읽기) : 어떤 경우에 가장 낮은 레벨이 될 수 없다 보장 된,
A로부터 D ---- 분리 레벨 높이에서 로우로의 낮은 레벨 높은 효율
3.InnoDB는 로우 레벨의 잠금을 지원한다. 행 레벨 잠금 동시 최대가 로우 레벨 락킹 스토리지 엔진 층에 의해 구현되는 지원할 수있다.
잠금 : 주요 역할 잠금은 트랜잭션 격리 구현하기위한 공유 자원에 대한 동시 액세스를 관리하는
유형 : 잠금 (잠금 읽기), 배타적 잠금 (쓰기 잠금) 공유
테이블 수준 잠금 (작은 오버 헤드, 동시성 : MySQL의 잠금 노력을 ) 저, 일반적으로 서버 계층에서 구현
행 수준 잠금 (큰 지출, 높은 동시성), 스토리지 엔진 수준에서 구현됩니다
4, 이노는 최대의 성능을 발휘하도록 설계 엄청난 양의 데이터를 처리 할 수 있도록 설계되어있다. 그 CPU 효율은 어느 디스크 기반 관계형 데이터베이스 엔진이 일치하지 않을 수 있습니다 될 수있다
5, InnoDB 스토리지 엔진은 완전히 메인 메모리에 캐시 데이터 및 인덱스에 MySQL 서버, InnoDB 스토리지 엔진과 통합 자체 버퍼 풀을 유지한다. InnoDB 테이블과 논리적 테이블 스페이스에 인덱스는, 테이블 스페이스가 파일 수 (디스크 파일 또는 원본)를 포함 할 수 있습니다
. 6, 이노 지원 외래 키 무결성 제약 조건은 테이블에 저장된 데이터는 각각의 테이블에 저장 기본 키 때 지정된 테이블 정의 표시되어 있지 않은 경우 기본 키를 저장하는 순서에 따른다. 이노 각 행 6 바이트 ROWID를 생성하고, 기본 키로
7, InnoDB의 많은 고성능에 사용되는 대형 데이터베이스 사이트에게 필요합니다
(: SELECT COUNT (*) 예를 들어, 이노되지 스토리지 테이블 행 8의 수를 에서 타임 테이블, InnoDB에 다시 행의 수를 계산하기 위해 전체 테이블을 스캔해야); ; 전체 테이블을 비우고, InnoDB하지만 라인으로 라인을 삭제하는 것입니다, 효율이 매우 느립니다
(의 MyISAM 엔진이 테이블 행의 수를 기록합니다)
InnoDB하지만 이노를 사용하여 디렉토리를 생성하지 않습니다, MySQL은 MySQL 데이터 디렉토리에을 ibdata1라는 파일을 생성합니다 ib_logfile0 크기 10MB의 자동 데이터 파일의 확장자, 2 개의 파일 이름 5메가바이트 로그 사이즈 ib_logfile1라는
이노 달성 개의 기본적인 엔진
이노 두 저장소 파일을 갖고, 각각 접미사 .FRM .idb; 상기 .FRM 테이블 정의 파일, 데이터 파일의 테이블 .idb이다.
1 이노 엔진 구조로 B + 트리 인덱스 구조를 사용하여
B-트리 (균형 탐색 트리 멀티플렉싱) 균형 탐색 트리 위해 설계 디스크 저장 장치로 로딩
디스크 블록이되는 디스크 메모리로부터 판독 된 시스템 데이터 비트의 기본 유닛은 하나 개의 디스크상의 데이터 블록이 판독 요구에 대신 한 번만 판독된다.
데이터 페이지 읽기로 InnoDB 스토리지 엔진을 사용하고, 페이지는 디스크 관리의 가장 작은 단위이며, 기본 페이지 크기가 16K.
디스크 블록 시스템의 저장 공간은 종종 그렇게 크지 않다, InnoDB는 따라서 각 응용 프로그램은 디스크 공간의 수있을 것입니다 16킬로바이트 페이지의 크기에 도달하는 연속 디스크 블록을 해결합니다.
이노 디스크의 수는 데이터를 쿼리 할 때, 각각의 데이터 페이지가 디스크를 줄일 기록 된 데이터의 위치를 찾는 데 도움이 될 수있는 경우, 디스크에 데이터가 페이지의 기본 단위가 될 것이다 읽을 때 I / O, 쿼리의 효율성을 향상시킬 수 있습니다.
B-트리 데이터 구조를 효율적으로 디스크를 찾기 위해 시스템을 허용한다면, 데이터 블록
각 노드 B 트리 실제 실시 예에있어서, 상기 키 정보와 분기 상당량을 함유 할 수있다 :
디스크 블록이 차지하는 디스크 공간의 각 노드는, 키워드의 오름차순으로 두 개의 포인터와 루트 노드의 자식 노드에 세 지점이 있습니다, 주소 포인터는 자식 노드가 위치한 디스크 블록에 저장됩니다.
루트, 키워드 예를 들어, 17 및 35에 대한 데이터 범위 P1 하위 트리 포인터 미만 (17), 상기 데이터 범위 P2 하위 트리 포인터 17 ---- 35 데이터 포인터 P3 하위 트리 35보다 큰 범위,
시뮬레이션 키워드 검색 순서로 29 :
루트 디스크 (1)를 발견에 따른 블록을 메모리로 판독된다. [처음으로 디스크의 I / O 동작]
B는 디스크 블록 포인터 P2를 찾으려면 부 (29) (17, 35)에서 키워드를 비교한다. (1) ;.
. C 디스크 블록 (3)은 포인터 P2와 같은 메모리로 읽어 실측치. [디스크 I / O 동작은 제]
디스크 블록 포인터 P2를 찾기 위해, 간격 (26, 30) 29 개 비교 키워드 거라고. 3 ;.
E 8 P2 메모리로 읽어 디스크 블록 포인터를 찾는. [디스크 I / O 작업을 세 번째]
F. 8 디스크 블록의 키워드 목록에서 29 찾기 키워드
의 MySQL의 InnoDB 스토리지 엔진이 때문에 영구 메모리를 근절하고, 설계는 트리의 깊이를 달성하기 위해 노력 즉, 3보다 더 많은 I / O는 3 배 이상을 필요로하지 않고,
상기 분석 결과는, 그 요구를 세 번 디스크 I / O 동작, 및 3 개 개의 메모리 룩업 동작을 발견 하였다. 때 세 번 디스크 I / O 작업을 찾을 수있는 B 트리의 전반적인 효율성에 영향을 미치는 인자를 결정하면서, 메모리 키가 정렬 된 목록 구조이기 때문에, 당신은 효율성을 개선하기 위해 이진 검색을 사용할 수 있습니다.
트리 + B
B + 트리 B- 트리에 기초하여 최적화 외부 메모리 인덱스 구조를 구현하는 것이 더 적합하게하고, B- 트리의 각 노드는 키를 가지고 데이터가 있으며, 메모리의 각 페이지는 데이터는 각 노드가 발생할 크면 제한된 데이터, 소수의 (즉, 페이지)를 키에 저장 될 수있다. 따라서 질의의 효율에 영향을 미치는 경우는 디스크 I / O 시간도 큰 깊이로 이끌 B 트리에 저장된 데이터의 양, 질의가 증가되는 경우.
B + 트리 노드가 모두 동일한 레벨의 리프 노드의 순서로 저장된 키 데이터 기록에 따라, 단지 저장 크게 각 노드에 저장된 키 값의 수를 늘릴 수있는 리프 노드 정보의 키 값, 환원 + 높이 트리, B,
B + 트리 B 트리에 기초하여 두 개의 변형되어있다 :; 저장된 일반적인 지수는 (1) 데이터가 존재하는 종단 노드 (마스터 키 ID 기억 기본 키 인덱스의 리프 노드 데이터의 전체 행)
(2) 데이터 노드에 대한 포인터 사이 (편리하게 검색 범위)
각 디스크 네 키 블록 포인터 정보를 저장할 수 있다고 가정 비 리프 노드 가기 만 키 정보의 B + 트리 이후, 아래와 같이 후 B + 트리 구조가된다 :
이 다른 키워드 최소 리프 노드를 가리키는 B + 트리의 루트 노드에 대한 포인터에 보통 두 개의 헤드 포인터가 있으며, 고리 구조는 모든 리프 노드 (즉, 노드 데이터) 사이에 체인입니다.
따라서이 검색 작업이 B + 트리에서 수행 할 수있는, 하나는 다른 하나는 루트 노드, 무작위 검색에서입니다, 기본 키 범위 검색하고 탭을 찾을 수 있습니다.
이노 B + 트리
이노 ID를 인덱스 데이터로서 저장된다
이노 엔진을 사용하여 두 개의 데이터 저장 파일이, 정의 파일은 데이터 파일이다.
B + 트리 구조 ID별로 이노 색인 및 리프 노드에 저장하는 레코드
인덱싱 필드가 기본 키 ID가 설정되지 않은 다음 필드가 인덱싱 된 후, 리프 노드에 저장된 경우에는 레코드의 기본 키 및 기본 키 인덱스는 해당 레코드를 찾을 수
참고 링크 : https://blog.csdn.net/m0_37962600/article/details/81005191