이 기사는 mysql에 대한 관련 지식을 제공합니다. 주로 데이터베이스 제조업체의 인터뷰 질문을 요약하여 모두에게 도움이 되기를 바랍니다.
추천 학습: mysql 비디오 튜토리얼
- 첫 번째 정규형(1NF): 더 이상 나눌 수 없는 테이블의 열을 나타내며 각 데이터베이스의 테이블 열은 분할할 수 없는 기본 데이터 항목이며 동일한 열에 여러 값이 있을 수 없습니다.
- 두 번째 정규형(2NF): 1NF를 기준으로 다음 두 부분도 포함됩니다. 첫째, 테이블에는 기본 키가 있어야 합니다. 둘째, 테이블의 기본 키가 아닌 열은 기본 키에 완전히 종속되어야 하며 기본 키의 일부에만 의존할 수 없습니다.
- 세 번째 정규 형식(3NF): 기본 2NF에서는 기본 키에 대한 기본 키가 아닌 열의 전이적 종속성이 제거되고, 기본 키가 아닌 열은 기본 키에 직접 종속되어야 합니다.
- BC 정규형(BCNF): 3NF를 기반으로 코드 부분에 대한 주요 속성의 전이적 종속성이 제거됩니다
2.1. 드라이버 및 데이터베이스 연결 풀 :
(1) 클라이언트는 데이터베이스와 통신하기 전에 데이터베이스 드라이버를 통해 MySQL과 연결을 설정한 후 SQL 문을 보냅니다.
(2) 잦은 연결 생성 및 파괴로 인한 시스템 성능 저하를 줄이기 위해 데이터베이스 연결 풀은 연결이 필요한 경우 연결 풀에서 직접 가져오고 사용 후 연결 스레드를 일정 수로 유지합니다. 연결 풀. 일반적인 데이터베이스 연결 풀에는 Druid, C3P0, DBCP
2.2 및 MySQL 아키텍처의 서버 계층 실행 프로세스가 포함됩니다.
(1) 커넥터: 주로 클라이언트와의 연결 설정, 권한 획득, 유지 및 관리를 담당합니다. connections
(2) 쿼리 캐시: 캐시에서 먼저 쿼리하고, 캐시에서 쿼리를 찾을 수 없으면 직접 반환합니다.
MySQL 캐시는 기본적으로 꺼져있습니다. 즉, 캐시 사용을 권장하지 않으며, MySQL8.0 버전에서는 전체 쿼리 캐시 기능이 삭제되었습니다. 이는 주로 사용 시나리오의 제한으로 인해 발생합니다.
- 먼저 캐시의 데이터 저장 형식에 대해 이야기하겠습니다. 키(sql 문) - 값(데이터 값)이므로 SQL 문(키)이 약간 다른 경우
- 테이블의 데이터는 정적이 아니므로 대부분 자주 변경되며 데이터베이스의 데이터가 변경되면 이 테이블과 관련된 해당 캐시된 데이터를 제거해야 합니다.
(3) 파서/분석기: 분석기의 역할은 주로 실행될 SQL 문에 대해 어휘 분석 및 구문 분석을 수행하고 최종적으로 추상 구문 트리를 얻은 후 전처리기를 사용하여 추상 구문 트리에 대한 의미 수정을 수행하는 것입니다. .추상 구문 트리에 테이블이 있는지 확인합니다. 테이블이 있으면 선택 프로젝션 열 필드가 있는지 확인합니다.
(4) 옵티마이저(Optimizer): 주로 SQL의 어휘 분석 및 구문 분석을 거쳐 얻은 구문 트리를 이용하여 데이터 사전의 내용과 통계 정보를 거쳐 일련의 연산을 거쳐 최종적으로 선택을 포함한 실행 계획을 도출한다.
인덱스 쿼리 사용 여부를 분석할 때 동적 데이터 샘플링 통계 분석을 통해 얻습니다. 통계적으로 분석되는 한 분석 오류가 발생할 수 있으므로 이를 사용하지 않고 SQL을 실행할 경우 index 를 사용하는 경우 이 요소도 고려해야 합니다.
(5) Executor: 일련의 실행 계획에 따라 스토리지 엔진에서 제공하는 API 인터페이스를 호출하여 작업 데이터를 호출하고 SQL 실행을 완료합니다.
2.3. Innodb 스토리지 엔진 실행 프로세스:
- (1) 먼저 MySQL 실행기는 스토리지 엔진의 API를 호출하여 실행 계획에 따라 데이터를 쿼리합니다.
- (2) 스토리지 엔진은 먼저 버퍼 풀에서 데이터를 쿼리합니다. 쿼리가 발견되면 캐시 풀에 넣습니다
- (3) 데이터를 버퍼 풀에 로드하는 동안 이 데이터의 원본 기록은 실행 취소 로그 파일에 저장됩니다
- (4) innodb는 버퍼 풀에서 업데이트 작업을 수행합니다
- (5) 업데이트된 데이터는 리두 로그 버퍼에 기록됩니다
- (6) 커밋 트랜잭션은 제출과 동시에 다음 세 가지 작업을 수행합니다
- (7) (첫 번째) 리두 로그 버퍼의 데이터를 리두 로그 파일에 플래시합니다
- (8) (두 번째) 작업 기록을 bin 로그 파일에 씁니다
- (9) (세 번째) bin을 넣습니다 bin 로그의 위치는 redo 로그에 기록되고, redo 로그 끝에 커밋 표시가 추가됩니다.
- (10) 백그라운드 스레드를 사용하여 업데이트된 데이터를 플러시합니다. 특정 기회에 MySQL 데이터베이스에 버퍼 풀을 추가하여 메모리와 데이터베이스의 데이터가 통합되도록 합니다
스토리지 엔진은 기반이 되는 물리적 데이터에 대해 실제 연산을 수행하는 구성요소로, 서버 서비스 계층의 데이터 운용을 위한 다양한 API를 제공합니다. 일반적으로 사용되는 스토리지 엔진에는 InnoDB, MyISAM 및 Memory가 있습니다. 여기서는 주로 InnoDB와 MyISAM의 차이점을 소개합니다.
(1) 트랜잭션: MyISAM은 트랜잭션을 지원하지 않고 InnoDB는 트랜잭션을 지원합니다.
(2) 잠금 수준: MyISAM은 테이블 수준 잠금만 지원하고 InnoDB는 행 수준 잠금을 지원하며 테이블 수준 잠금은 기본적으로 행 수준 잠금이 사용되지만 행 잠금은 인덱스를 통해 데이터를 쿼리할 때만 사용되며, 그렇지 않으면 테이블 잠금이 사용됩니다. 행 수준 잠금은 잠금을 획득하고 해제하는 각 작업에서 테이블 잠금보다 더 많은 리소스를 소비합니다. 행 잠금을 사용하면 교착 상태가 발생할 수 있지만 테이블 수준 잠금을 사용하면 교착 상태가 없습니다
(3) 기본 키와 외래 키: MyISAM은 인덱스와 기본 키가 없는 테이블의 존재를 허용하며 외래 키를 지원하지 않습니다. InnoDB의 기본 키는 비워둘 수 없으며 기본 키 자동 증가를 지원합니다. 기본 키 또는 비어 있지 않은 고유 인덱스가 설정되지 않은 경우 6바이트 기본 키가 자동으로 생성되고 외래 키 무결성 제약 조건을 지원합니다
(4) 인덱스 구조: MyISAM과 InnoDB는 모두 B+ 트리 인덱스를 사용합니다. MyISAM의 기본 키 인덱스와 보조 인덱스의 데이터 필드는 행 데이터 레코드가 저장되는 주소입니다. 그러나 InnoDB 기본 키 인덱스의 Data 필드에는 행 데이터 레코드의 주소가 아닌 해당 행의 모든 데이터 내용이 저장되는 반면, 보조 인덱스의 Data 필드에는 기본 인덱스의 값이 저장됩니다.
InnoDB의 보조 인덱스는 기본 키 인덱스의 값을 저장하므로 보조 인덱스를 사용하려면 인덱스를 두 번 검색해야 합니다. 먼저 보조 인덱스를 검색하여 기본 키를 얻은 다음 기본 키를 사용하여 기본 인덱스. 이것이 너무 긴 필드를 기본 키로 사용하는 것을 권장하지 않는 이유입니다. 보조 인덱스에는 기본 키 열이 포함되어 있으므로 기본 키가 너무 긴 필드를 사용하면 다른 보조 인덱스가 더 커지게 되므로 기본 키는 가능한 한 작게 만듭니다.
(5) 전체 텍스트 인덱스: MyISAM은 버전 5.6 이전에는 전체 텍스트 인덱스를 지원하지 않았습니다.
(6) 특정 번호. of columns in the table:
(7) 저장 구조:
(8) 저장공간 :
(9) 적용 가능한 시나리오:
참고: MyISAM 스토리지 엔진은 mysql8.0에서 폐기되었습니다. 버전
데이터베이스 트랜잭션은 동시성 제어의 기본 단위로, 모두 실행되거나 전혀 실행되지 않는 논리적 작업 집합을 나타냅니다.
4.1 거래 ACID:
- (1) 원자성: 트랜잭션은 분할할 수 없는 작업 단위입니다. 트랜잭션의 작업은 성공하거나 실패합니다.
- (2) 격리: 트랜잭션에 의해 운영되는 데이터가 제출되기 전에 다른 트랜잭션에 표시되는 정도입니다.
- (3) 지속성: 트랜잭션이 커밋되면 데이터베이스의 데이터 변경 사항이 영구적입니다.
- (4) 일관성: 거래는 데이터 무결성과 비즈니스 일관성을 파괴할 수 없습니다. 예를 들어, 돈을 이체할 때 거래가 성공하든 실패하든 양측 간의 총 금액은 변하지 않습니다.
4.2. ACID 구현 원칙:
4.2.1. 원자성: MySQL의 롤백 로그 실행 취소 로그를 통해 달성됩니다. 트랜잭션이 실행되면 InnoDB는 해당 실행 취소 로그를 생성합니다. 실패하거나 롤백이 호출되어 트랜잭션이 롤백되는 경우 실행 취소 로그의 정보를 사용하여 데이터를 수정 전의 방식으로 롤백할 수 있습니다. 来
4.2.2. 격리:
(1) 트랜잭션 격리 수준:
동시 환경에서 데이터 읽기의 무결성과 일관성을 보장하기 위해 데이터베이스는 4가지 트랜잭션 격리 수준을 제공합니다. 격리 수준이 높을수록 , 데이터가 더욱 완전하고 일관되게 보장될 수 있지만, 높은 동시성 성능에 미치는 영향이 커지고 실행 효율성이 낮아집니다. (4개의 격리 수준은 위에서 아래로 증가합니다)Read Uncommitted: 트랜잭션이 실행 중에 다른 트랜잭션의 커밋되지 않은 데이터를 읽을 수 있도록 허용합니다.
- Read Committed: 실행 중에 트랜잭션을 읽을 수 있습니다.
- 반복 읽기(기본 수준): 동일한 트랜잭션 내에서 언제든지 쿼리 결과가 일관됩니다.
- 읽기 직렬화: 모든 트랜잭션은 하나씩 실행되며, 각 읽기에는 테이블 수준 공유 잠금이 필요합니다. , 읽기와 쓰기가 서로 차단됩니다.
(2) 트랜잭션 동시성 문제:
트랜잭션의 격리를 고려하지 않으면 트랜잭션 동시성 환경에서 문제가 발생할 수 있습니다.다른 트랜잭션 격리 수준은 동시 환경에서 다른 동시성 문제를 갖습니다.업데이트 손실: 두 개 이상의 트랜잭션 작업이 동일한 경우 그런 다음 선택한 값을 기반으로 데이터가 업데이트됩니다. 각 트랜잭션은 다른 트랜잭션의 존재를 인식하지 못하기 때문에 업데이트 손실 문제가 발생합니다. 마지막 업데이트가 다른 트랜잭션의 업데이트를 덮어씁니다.
- 더티 읽기(Dirty read): 트랜잭션 A가 데이터에 액세스하고 데이터를 수정했음을 의미합니다(트랜잭션이 커밋되지 않음). 나중에 트랜잭션 A가 롤백을 취소하고 수정된 데이터를 원래 위치로 복원합니다. 원래 값. B가 읽은 데이터는 데이터베이스의 데이터와 일치하지 않습니다. 즉, B가 읽은 데이터는 더티 데이터입니다.
- 비반복 읽기: 한 트랜잭션 내에서 동일한 데이터를 여러 번 읽지만, 이 기간 동안 다른 트랜잭션이 데이터를 수정하고 커밋했기 때문에 전후에 읽은 데이터가 일치하지 않습니다.
- 팬텀 읽기: 트랜잭션에서, 동일한 데이터(일반적으로 범위 쿼리)를 두 번 읽지만 다른 트랜잭션에서 데이터를 추가하거나 삭제하기 때문에 두 번의 결과가 일치하지 않습니다.
(3) 트랜잭션 격리 구현 원칙:
Innodb 트랜잭션 격리 수준은 MVVC 및 잠금 메커니즘에 의해 결정됩니다. 구현:① MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)는 MySQL의 InnoDB 스토리지 엔진이 트랜잭션 격리 수준을 구현하는 특정 방법으로 읽기 커밋 및 반복 가능 읽기의 두 가지 격리 수준을 구현하는 데 사용됩니다. 커밋되지 않은 읽기 격리 수준은 MVCC를 사용하지 않고 항상 최신 데이터 행을 읽습니다. 읽기 직렬화 격리 수준에서는 모든 읽기 행을 잠가야 하는데 이는 단순히 MVCC를 사용하여 달성할 수 없습니다. MVCC는 레코드의 각 행 뒤에 두 개의 숨겨진 열을 저장하여 구현됩니다. 하나는 행의 트랜잭션 ID를 저장하고 다른 하나는 행의 롤백 세그먼트 포인터를 저장합니다. 새로운 거래가 시작될 때마다 새로운 거래 ID가 자동으로 증가됩니다. 트랜잭션이 시작되면 현재 트랜잭션의 영향을 받는 행의 트랜잭션 ID 필드에 트랜잭션 ID가 배치되고 롤백 세그먼트의 포인터에는 행 레코드의 모든 버전 데이터가 링크된 형태로 구성됩니다. undo 로그 롤백 로그의 목록, 즉 해당 값이 실제로 실행 취소 로그 행의 히스토리 연결 목록을 가리킨다고 합니다. 데이터베이스에 동시에 접근할 때 트랜잭션 내 데이터에 대해 MVCC 다중 버전 관리를 수행하여 쓰기 작업이 읽기 작업을 차단하는 것을 방지하고 스냅샷 읽기 방식의 팬텀 읽기 문제는 버전 비교를 통해 해결할 수 있지만 팬텀의 경우 현재 읽기의 읽기, MVCC는 이를 해결할 수 없으며 임시 키 잠금으로 해결해야 합니다. ② 잠금 메커니즘: MySQL 잠금 메커니즘의 기본 작동 원리는 다음과 같습니다. 트랜잭션이 데이터베이스를 수정하기 전에 해당 잠금을 획득해야 합니다. 잠금을 획득한 트랜잭션만 트랜잭션 작업 중에 데이터를 수정할 수 있습니다. , 데이터의 이 부분은 잠금입니다. 다른 트랜잭션이 데이터를 수정해야 하는 경우 현재 트랜잭션이 커밋되거나 롤백되어 잠금을 해제할 때까지 기다려야 합니다.
- 배타적 잠금은 더티 읽기를 해결합니다.
- 공유 잠금은 반복 불가능한 읽기를 해결합니다.
- 프로 키 잠금은 팬텀 읽기를 해결합니다.
4.2.3 지속성:
지속성은 ,
SQL 실행 시 리두 로그에 의존합니다. 실행된 SQL 문은 Redo 로그 파일에 저장되지만 효율성을 높이기 위해 Redo 로그에 데이터를 쓰기 전에 먼저 메모리의 Redo 로그 버퍼 캐시에 기록됩니다. 쓰기 프로세스는 다음과 같습니다: 데이터베이스에 데이터를 쓸 때 실행 프로세스는 먼저 리두 로그 버퍼에 기록됩니다. 리두 로그 버퍼의 수정된 데이터는 정기적으로 디스크의 리두 로그 파일로 새로 고쳐집니다. 디스크 플러싱(즉, 리두 로그 버퍼가 디스크의 리두 로그 파일에 로그를 기록함)이라고 합니다.
리두 로그 버퍼를 사용하면 데이터 읽기 및 쓰기 효율성이 크게 향상될 수 있지만 새로운 문제도 발생합니다. MySQL이 다운되고 리두 로그 버퍼에서 수정된 데이터가 메모리의 디스크에 플러시되지 않은 경우 , 데이터 손실로 이어질 수 있으며 거래의 내구성을 보장할 수 없습니다. 트랜잭션의 내구성을 보장하기 위해 트랜잭션이 커밋되면 fsync 인터페이스가 다시 실행 로그를 플러시하도록 호출됩니다. 새로 고침 빈도는 innodb_flush_log_at_trx_commit 변수에 의해 제어됩니다.
- 0: 디스크를 플러시하지 않음을 의미합니다.
- 1: 모든 트랜잭션 트랜잭션이 제출되면 버퍼 풀의 데이터가 디스크로 플러시됩니다.
- 2: 트랜잭션이 제출되면 버퍼 풀의 데이터가 디스크에 해당하는 OS 캐시에 기록됩니다. 파일을 직접 입력하는 대신 . OS 캐시의 데이터가 디스크 파일에 기록되기까지 1초 정도 걸릴 수 있습니다.
4.2.4. 일관성:
일관성은 트랜잭션이 데이터 무결성과 비즈니스 일관성을 파괴할 수 없다는 사실을 나타냅니다.
데이터 무결성: 엔터티 무결성, 열 무결성(예: 필드 유형, 크기, 길이) 요구 사항을 충족해야 함), 외래 키 제약 조건 등
비즈니스 일관성: 예를 들어 은행 송금의 경우 거래 성공 여부에 관계없이 양 당사자 간의 총액은 변경되지 않습니다.
데이터베이스의 여러 트랜잭션이 동일한 데이터에 동시에 액세스할 때 동시 작업을 제어하지 않으면 잘못된 데이터를 읽고 저장하여 데이터베이스의 일관성이 파괴될 수 있습니다. MySQL 잠금 메커니즘의 기본 작동 원리는 트랜잭션이 데이터베이스를 수정하기 전에 먼저 해당 잠금을 획득해야 한다는 것입니다. 잠금을 획득한 트랜잭션만 트랜잭션 작업 중에 데이터를 수정할 수 있습니다. 다른 트랜잭션에서 이를 수정해야 하는 경우 데이터는 현재 트랜잭션이 커밋되거나 롤백되어 잠금이 해제될 때까지 기다려야 합니다.
다양한 분류 방법에 따라 잠금 유형은 다음과 같은 유형으로 나눌 수 있습니다.잠금의 세분성으로 구분: 테이블 수준 잠금, 행 수준 잠금, 페이지 수준 잠금
- 잠금 유형으로 구분: 공유(잠금 S 잠금), 배타적 잠금(X 잠금)
- 잠금 사용 전략으로 구분: 낙관적 잠금, 비관적 잠금
5.1, 테이블 수준 잠금, 행 수준 잠금, 페이지 수준 잠금:
다양한 스토리지 엔진이 다양한 잠금 메커니즘을 지원합니다.테이블 수준 잠금: 세분성이 가장 큰 잠금 수준, 잠금 충돌 가능성이 가장 높고 동시성은 가장 낮지만 오버헤드가 적고 잠금이 빠릅니다.
- 행 수준 잠금: 발생률이 가장 작은 수준 잠금 충돌 가능성이 가장 작고 동시성이 가장 높지만 비용이 많이 들고 잠금 추가 속도가 느리며 교착 상태가 발생합니다.
- 페이지 수준 잠금: 잠금 세분성은 테이블 수준 잠금과 행 수준 잠금 간에 제한됩니다. 잠금은 절충안이며 동시성은 평균입니다. 오버헤드와 잠금 시간도 테이블 잠금과 행 잠금 간에 제한되며 교착 상태가 발생합니다.
InnoDB 스토리지 엔진은 행 수준 잠금과 테이블 수준 잠금을 지원합니다. 행 수준 잠금은 기본적으로 사용되지만 행 수준 잠금은 인덱스를 통해 데이터를 쿼리할 때만 사용되며, 그렇지 않은 경우에는 테이블 수준 잠금이 사용됩니다.
- MyISAM 및 MEMORY 스토리지 엔진은 테이블 수준 잠금을 사용합니다.
- BDB 스토리지 엔진은 페이지 잠금을 사용하지만 테이블 수준 잠금도 지원합니다.
5.2, InnoDB 행 잠금:
InnoDB 행 잠금 잠금 유형:업데이트, 삭제 및 삽입 작업의 경우 InnoDB는 일반 SELECT 문과 관련된 데이터 행에 자동으로 배타적 잠금을 추가하지만 InnoDB는 잠금을 추가하지 않습니다.
5.3. InnoDB 테이블 잠금 및 의도 잠금:
InnoDB 엔진은 행 잠금과 테이블 잠금의 공존을 허용하여 다중 세분성 잠금 메커니즘을 구현하지만 테이블 잠금과 행 잠금은 서로 충돌합니다. 그들은 서로 다른 잠금 범위를 가지고 있습니다. 테이블 잠금을 추가하려면 먼저 테이블의 모든 레코드를 탐색하여 배타적 잠금이 있는지 확인해야 합니다. 이 순회 확인 방법은 분명히 비효율적인 방법입니다. MySQL은 테이블 잠금과 행 잠금 간의 충돌을 감지하기 위해 의도 잠금을 도입합니다.의도 잠금은 테이블 수준 잠금이기도 하며 읽기 의도 잠금(IS 잠금)과 쓰기 의도 잠금(IX 잠금)으로 구분됩니다. 트랜잭션이 레코드에 행 잠금을 추가하려는 경우 먼저 해당 의도 잠금을 테이블에 추가합니다. 나중에 트랜잭션이 테이블을 잠그려면 먼저 의도한 잠금이 존재하는지 여부만 확인하면 됩니다. 존재하는 경우 테이블 잠금을 빠르게 설정할 수 없습니다. 그렇지 않으면 효율성을 높이기 위해 기다려야 합니다.
5.4. InnoDB 행 잠금 및 키 잠금 구현:
InnoDB 행 잠금은 인덱스의 인덱스 항목을 잠그는 방식으로 구현됩니다. 행 잠금은 인덱스를 통해 데이터를 검색할 때만 사용할 수 있으며, 그렇지 않으면 테이블 잠금이 사용됩니다.
InnoDB에서는 팬텀리딩 현상을 해결하기 위해 넥스트키 잠금(next-key)을 도입했습니다. 지수에 따라 왼쪽이 열린 구간, 오른쪽이 닫힌 구간으로 구분됩니다. 범위 쿼리 수행 시 인덱스에 도달하여 데이터를 검색할 수 있으면 해당 레코드가 있는 간격과 다음 간격이 잠깁니다. 실제로 Next-Key = Record Locks + Gap Locks
- Gap Locks: 정확한 쿼리 대신 범위 쿼리를 사용하여 데이터를 검색하고 공유 또는 배타적 잠금을 요청할 때 InnoDB는 기존 데이터 레코드의 인덱스 항목을 잠급니다. 범위 조건을 충족하는 경우, 키 값이 조건 범위 내에 있지만 존재하지 않는 레코드를 간격(GAP)이라고 합니다.
- 레코드 잠금: 고유 인덱스와 레코드 존재에 대한 정확한 쿼리를 사용할 때 레코드 잠금을 사용하세요
5.5, 잠금 메커니즘을 사용하여 동시성 문제를 해결합니다.
- X 잠금은 더티 읽기를 해결합니다
- S 잠금 반복 불가능한 읽기 문제 해결
- Pro-key 잠금으로 팬텀 읽기 문제 해결
InnoDB 스토리지 엔진의 잠금 메커니즘과 MyISAM 스토리지 엔진의 잠금 메커니즘에 대한 자세한 내용은 MySQL 데이터베이스: 잠금 메커니즘_Zhang을 참조하세요. 데이터베이스의 Weipeng Blog-CSDN Blog_Lock 메커니즘
인덱스는 기본적으로 탐색해야 하는 행 수를 줄여 쿼리 성능을 높이고 전체 쿼리를 방지하는 데이터 구조입니다. 책의 목차와 마찬가지로 데이터베이스의 테이블 스캔을 통해 콘텐츠를 더 빠르게 찾을 수 있습니다. (테이블은 최대 16개까지 가능)
6.1.인덱스의 장점과 단점:
(1) 인덱스의 장점:쿼리로 검색해야 하는 행 수 감소, 속도 쿼리를 실행하고 전체 테이블 스캔을 피하세요. 이는 인덱스를 생성하는 주된 이유이기도 합니다.
(2) 인덱스의 단점:- 인덱스의 데이터 구조가 B+ 트리인 경우 그룹화 및 정렬을 사용하면 쿼리에서 그룹화 및 정렬하는 시간을 크게 줄일 수 있습니다.
- 고유 인덱스를 생성하면 데이터베이스 테이블에 있는 각 데이터 행의 고유성을 보장할 수 있습니다.
테이블의 데이터가 추가, 삭제, 수정될 때 인덱스도 업데이트해야 하며, 데이터 양이 증가함에 따라 유지 관리 시간도 늘어납니다.
- 인덱스는 물리적 공간을 차지해야 합니다. 클러스터형 인덱스를 만들려면 필요한 공간이 더 커집니다.
6.2. 인덱스 사용 시나리오:
(1) 인덱스를 생성할 열:6.3. 인덱스 분류:WHERE 절에 자주 나타나는 열에 인덱스를 생성하여 조건 판단 속도를 높입니다.
차별성이 크지 않은 열입니다. 이러한 열은 쿼리 결과에서 성별과 같은 값이 거의 없기 때문에 결과 집합의 데이터 행은 테이블의 데이터 행 중 많은 부분을 차지합니다. 테이블에서 검색했습니다. 인덱스를 늘려도 검색 속도는 크게 향상되지 않습니다.- 범위로 접근하는 열이나 그룹화 또는 정렬 기준으로 사용되는 열은 인덱스가 정렬되어 있으므로 인덱스를 사용하면 정렬 쿼리 시간을 단축할 수 있습니다.
- 연결된 열에 자주 사용되는 이 열은 주로 외래 키이므로 연결 속도를 높일 수 있습니다.
- 기본 키 열로서 열의 고유성을 강화하고 테이블의 데이터 배열 구조를 구성합니다.
- (2) 색인을 생성하면 안 되는 열은 무엇인가요?
- 쿼리에서 거의 사용되지 않는 열은 색인화하면 안 됩니다. 이러한 열은 거의 사용되지 않으므로 인덱스를 추가하면 실제로 시스템 유지 관리 속도가 줄어들고 공간 요구 사항이 늘어납니다.
- 인덱스를 추가하면 검색 성능 향상보다 수정 비용 증가가 훨씬 클 경우 인덱스를 생성하면 안 됩니다. 인덱스를 추가하면 검색 성능은 향상되지만 수정 성능은 저하됩니다. 인덱스를 줄이면 수정 성능이 향상되고 검색 성능이 저하됩니다.
- 텍스트, 이미지, 비트 데이터 형식으로 정의된 열은 색인화하면 안 됩니다. 이러한 열의 데이터 볼륨은 상당히 크거나 값이 거의 없습니다.
(1) 일반 인덱스, 고유 인덱스, 기본 키 인덱스, 전체 텍스트 인덱스, 결합 인덱스.
- 일반 인덱스: 아무런 제한이 없는 가장 기본적인 인덱스
- 고유 인덱스: 단, 인덱스 열의 값은 고유해야 하며, null 값이 허용되며, NULL 값이 여러 개 있을 수 있습니다. 복합 인덱스의 경우 컬럼 값의 조합이 고유해야 합니다.
- 기본 키 인덱스: null 값을 허용하지 않는 특수 고유 인덱스입니다.
- 전체 텍스트 인덱스: 전체 텍스트 인덱스는 MyISAM 테이블에만 사용할 수 있으며 CHAR, VARCHAR 또는 TEXT 유형만 지원합니다. 퍼지 일치 작업과 같이 덜 효율적인 대체에 사용되며 일회성 전체에 사용할 수 있습니다. 다중 필드 결합 전체 텍스트 인덱스를 통한 퍼지 일치.
- 결합 인덱스: 주로 MySQL의 효율성을 높이기 위해 복합 인덱스를 생성할 때 제한 조건으로 가장 일반적으로 사용되는 열을 내림차순으로 맨 왼쪽에 배치해야 합니다.
(2) 클러스터형 인덱스와 비클러스터형 인덱스:
데이터가 저장되는 물리적 순서와 인덱스 값의 순서에 따라 분류하면 인덱스는 클러스터형 인덱스와 비클러스터형 인덱스 두 가지로 나눌 수 있습니다. :
6.4. 인덱스 데이터 구조:
- 클러스터형 인덱스: 테이블의 데이터 저장 순서는 인덱스 값의 순서와 일치합니다. 기본 테이블은 클러스터형 인덱스 열의 데이터를 업데이트할 때 최대 1개만 가질 수 있습니다. 변경 사항은 비용이 많이 들기 때문에 자주 업데이트되는 열에 대해 클러스터형 인덱스를 설정하는 것은 적절하지 않습니다. 인덱스 값의 순서와 일치하지 않습니다. 기본 테이블에는 여러 클러스터가 있을 수 있습니다.
일반적인 인덱스 데이터 구조에는 B+Tree, Hash 인덱스가 포함됩니다.
(1) 해시 인덱스: MySQL의 메모리 스토리지 엔진만이 메모리 테이블의 기본 인덱스 유형인 해시 인덱스를 지원합니다. 해시 인덱스는 데이터를 해시값 형태로 정리하므로 쿼리 효율이 매우 높고 한 번에 찾을 수 있다.
해시 인덱스의 단점:해시 인덱스는 동일한 값 쿼리만 만족할 수 있지만 범위 쿼리 및 정렬은 만족할 수 없습니다. 데이터가 해시 알고리즘을 통과한 후 크기 관계가 변경될 수 있기 때문입니다.B+트리 인덱스의 장점:(2) B+Tree 인덱스: B+Tree는 mysql에서 가장 많이 사용되는 인덱스 데이터 구조로 Innodb와 Myisam 스토리지 엔진 모드의 인덱스 유형이다. B+Tree 인덱스는 검색 시 루트 노드부터 리프 노드까지 여러 번의 IO 작업이 필요합니다. 쿼리 속도는 Hash 인덱스만큼 좋지는 않지만 정렬과 같은 작업에는 더 적합합니다.
- 복합 인덱스 생성 시, 복합 인덱스의 일부 컬럼만 쿼리에 사용할 수는 없습니다. 해시 인덱스는 여러 컬럼 데이터를 결합한 후 해시 값을 계산하기 때문에 개별 컬럼 데이터에 대한 해시 값을 계산하는 것은 의미가 없습니다.
- 해시 충돌이 발생하면 해시 인덱스는 테이블 데이터 스캔을 피할 수 없습니다. 단순히 Hash 값을 비교하는 것만으로는 충분하지 않기 때문에 실제 값을 비교하여 요구 사항을 충족하는지 판단해야 합니다.
페이지 내 노드는 콘텐츠를 저장하지 않으며 IO당 더 많은 행을 읽을 수 있어 디스크 I/O 읽기 횟수가 크게 줄어듭니다.6.5. B+Tree를 인덱스로 사용하는 이유:
- 순차 액세스 포인터가 있는 B+트리: B+Tree의 모든 인덱스 데이터는 리프 노드에 저장되며, 각 리프 노드에는 인접한 리프 노드에 대한 포인터가 추가됩니다. 이는 간격 쿼리의 효율성을 높이기 위해 수행됩니다.
인덱스 자체도 매우 크고 메모리에 모두 저장하는 것이 불가능하므로
인덱스는 인덱스 형태로 디스크에 저장되는 경우가 많습니다. 파일. 이 경우 인덱스 검색 과정에서 디스크 I/O 소비가 발생하게 되며, 메모리 액세스에 비해 디스크 I/O 액세스 소비가 몇 배 더 높기 때문에 가장 중요한 것은 인덱스 검색의 품질을 평가하는 것입니다. 인덱스로서의 데이터 구조 지표는 검색 프로세스 중 디스크 I/O 작업 수의 점근적 복잡성을 나타냅니다. 즉,index의 데이터 구조는 검색 과정에서 디스크 I/O 액세스 횟수를 최소화해야 합니다. (1) 지역성 원리 및 프로그램 사전 읽기:
디스크 자체는 메인 메모리에 비해 접근 속도가 훨씬 느리고 기계적 이동 비용도 더해지므로 효율성을 높이기 위해서는 디스크 I/O가 반드시 필요합니다. 최소화. 이 목표를 달성하기 위해 디스크는 엄격하게 요구에 따라 읽는 것이 아니라 매번 미리 읽는 경우가 많습니다. 1바이트만 필요하더라도 디스크는 이 위치에서 시작하여 일정 길이의 데이터를 순차적으로 읽어옵니다. 메모리. 이에 대한 이론적 근거는 컴퓨터 과학의 유명한 지역성 원칙입니다. 즉, 데이터 조각이 사용될 때 일반적으로 근처의 데이터가 즉시 사용됩니다. 프로그램 실행 중에 필요한 데이터는 일반적으로 집중되어 있습니다.디스크 순차 읽기는 매우 효율적이므로(탐색 시간이 필요하지 않고 회전 시간이 매우 적음) 미리 읽기는 지역성이 있는 프로그램의 I/O 효율성을 향상시킬 수 있습니다. 미리 읽기의 길이는 일반적으로 페이지의 정수배입니다. 프로그램이 읽을 데이터가 메인 메모리에 없으면 페이지 폴트 예외가 발생합니다. 이때 시스템은 읽기 신호를 디스크에 보내고 디스크는 데이터의 시작 위치를 찾습니다. 하나 이상의 페이지를 거꾸로 읽습니다. 메모리에 로드한 다음 비정상적으로 반환되고 프로그램이 계속 실행됩니다.
(2) B+Tree 지수 성능 분석: 위에서 언급했듯이 일반적으로 디스크 I/O 수는 인덱스 구조의 품질을 평가하는 데 사용됩니다. B-트리 분석부터 시작해 보겠습니다. B-트리 검색에는 최대 h개의 노드에 대한 액세스가 필요합니다. 동시에 데이터베이스는 디스크 미리 읽기 원칙을 교묘하게 사용하여 노드 크기를 한 페이지와 동일하게 설정합니다. 즉, 새 노드가 생성될 때마다 페이지 공간이 직접 생성되어 노드가 페이지에 물리적으로 저장되고 컴퓨터 스토리지 할당이 페이지 정렬되어 각 노드가 완전히 로드될 수 있습니다. I/O가 하나만 있으면 됩니다. B-트리에서 검색하려면 최대 h-1 I/O(루트 노드가 메모리에 상주함)가 필요하며 시간 복잡도는 O(h)=O(logdN)입니다. 일반적인 실제 적용에서 외향차 d는 매우 큰 수(보통 100 이상)이므로 h는 매우 작습니다. 정리하자면, B-트리를 인덱스 구조로 사용하는 것은 매우 효율적입니다. 레드-블랙 트리와 같은 구조의 경우 시간 복잡도도 O(h)이지만 h는 분명히 훨씬 더 깊고 논리적으로 가까운 노드는 물리적으로 멀리 떨어져 있을 수 있으므로 지역성을 활용할 수 없습니다. 분명히 B-tree보다 훨씬 나쁩니다. 또한 인덱스 데이터 구조로는 B+Tree가 더 적합한 이유는 내부 노드의 외부 차수 d와 관련이 있습니다. 위의 분석을 통해 d가 클수록 인덱스 성능이 좋아지는 것을 알 수 있으며, 데이터 도메인이 제거되므로 아웃 차수 d의 상한은 노드의 키와 데이터 크기에 따라 달라집니다. B+트리의 노드에서 더 큰 외부 수준을 가질 수 있으므로 디스크 IO 수가 더 적습니다. (3) B+트리 인덱스와 B-트리 인덱스 비교? B-Tree와 B+Tree의 구조에 따르면 파일 시스템이나 데이터베이스 시스템에서 B+ 트리가 B-tree보다 더 많은 이점을 가지고 있음을 알 수 있습니다. (4) MySQL의 InnoDB 및 MyISAM 스토리지 엔진에 B+Tree 인덱스를 구현합니까? MyISAM과 InnoDB는 모두 B+ 트리 인덱스를 사용합니다. MyISAM의 기본 키 인덱스와 보조 인덱스의 데이터 필드는 모두 행의 주소를 저장하지만 InnoDB의 기본 키 인덱스는 행의 주소가 아닌 행의 모든 데이터를 저장합니다. , 보조 인덱스의 데이터 필드에는 기본 인덱스의 값이 저장됩니다. 인덱스 길이 제한: (1) MySQL SQL 최적화 및 인덱스 최적화: https://blog.csdn.net/a745233700/article/details/84455241 (2) MySQL 테이블 구조 최적화: https://blog.csdn .net/a745233700/article/details /84405087 MySQL은 IO 집약적 애플리케이션이며 주요 책임은 데이터 관리 및 저장입니다. 그리고 우리는 메모리에서 데이터베이스를 읽는 시간이 마이크로초 수준인 반면, 일반 하드 디스크에서 IO를 읽는 시간은 밀리초 수준이라는 것을 알고 있습니다. 둘 사이의 차이는 3배입니다. 따라서 데이터베이스를 최적화하기 위해 가장 먼저 최적화해야 할 단계는 IO이며, 디스크 IO를 메모리 IO로 최대한 변환합니다. 따라서 MySQL 데이터베이스의 매개변수를 최적화할 때 우리는 주로 디스크 IO를 줄이는 매개변수를 최적화합니다. 예를 들어 query_cache_size를 사용하여 쿼리 캐시의 크기를 조정하고 innodb_buffer_pool_size를 사용하여 버퍼 크기를 조정합니다. 실행 계획은 쿼리 분석기를 거친 후 SQL 문에서 얻은 추상 구문 트리와 관련 테이블의 통계 정보를 기반으로 한 쿼리 계획입니다. 생성된 쿼리 최적화 프로그램에 의해. 동적 데이터 샘플링과 통계적 분석의 결과이므로 분석 오류, 즉 실행 계획이 최적이 아닐 수 있습니다. Explain 키워드를 사용하면 MySQL이 SQL 쿼리 문을 실행하는 방법을 알고, select 문의 성능 병목 현상을 분석하고, 쿼리를 개선할 수 있습니다. 중요한 것은 id, type, key입니다. key_len, androws, extra: (1) id: id 열은 SQL 실행 순서의 식별자로 이해될 수 있습니다. (3) 테이블: explain 행이 어느 테이블에 접근하는지 나타냄 (4) 유형: 액세스 유형, 즉 MySQL이 테이블에서 행을 찾는 방법을 결정합니다. 최고에서 최악까지: system > const > eq_ref > index_merge > index_subquery > index > index_merge를 제외하고 다른 유형은 하나의 인덱스만 사용할 수 있습니다. 일반적으로 유형은 참조 수준에 있어야 하며 범위 검색은 범위 수준에 도달해야 합니다. (6) key : 이 테이블에 대한 액세스를 최적화하기 위해 실제로 사용되는 인덱스 (7) key_len: 쿼리를 최적화하기 위해 실제로 사용되는 인덱스 길이, 즉 인덱스에 사용되는 바이트 수입니다. 이 값을 통해 다중 컬럼 인덱스에서 실제로 인덱스의 어떤 필드가 사용되는지 계산할 수 있습니다. (8)ref: 키와 함께 사용되는 필드 또는 상수를 표시합니다. (9)rows: 테이블 통계 및 인덱스 선택을 기반으로 정확한 수치가 아닌 쿼리를 위해 읽어야 하는 행 수를 대략적으로 추정합니다. 값. (10)추가: 기타 추가 정보 10.1. MySQL 마스터-슬레이브 복제의 원리: 슬레이브는 마스터에서 binlog 바이너리 로그 파일을 가져온 다음 로그 파일을 해당 SQL 문을 슬레이브 서버에서 다시 실행하여 데이터 일관성을 보장합니다. 마스터-슬레이브 복제 과정은 비동기식이므로 슬레이브와 마스터 간 데이터 지연이 발생할 수 있으며, 데이터의 최종 일관성만 보장할 수 있습니다. 마스터와 슬레이브 사이의 전체 복제 프로세스는 주로 세 가지 스레드에 의해 완료됩니다. 참고: 마스터 서버에 두 개의 슬레이브 서버가 있는 경우 두 개의 슬레이브 서버가 있습니다. 마스터 서버. Binlog 덤프 스레드, 각 슬레이브 서버에는 두 개의 스레드가 있습니다. 10.2. 마스터-슬레이브 복제 프로세스: 10.3. 마스터-슬레이브 복제의 이점: 10.4 MySQL에서 지원하는 복제 유형과 그 장점과 단점: binlog 로그 파일에는 두 가지 형식이 있습니다. 하나는 명령문 기반(명령문 기반 복제)이고 다른 하나는 행 기반(기반)입니다. 행 복사). 기본 형식은 명령문 기반입니다. 형식을 변경하려면 서비스 시작 시 -binlog-format 옵션을 사용하십시오. mysqld_safe –user=msyql –binlog-format=format& (1) 명령문 기반 복제: 마스터 서버에서 실행되는 SQL 문과 슬레이브 서버에서 동일한 명령문이 실행되는 것입니다. 효율성이 상대적으로 높습니다. 정확한 복사가 불가능하다는 것이 확인되면 행 기반 복사가 자동으로 선택됩니다. 장점: 단점: (2) 행 기반: 슬레이브 서버에서 명령을 실행하는 대신 변경된 내용을 복사합니다. mysql5.0부터 지원됩니다. 장점: 단점: (3) 혼합형 복제 : 기본적으로 명령문 기반 복제를 채택하며, 명령문 기반 복제가 정확하지 않다고 판단되면 행 기반 복제를 채택합니다. 마스터-슬레이브 복제에 대한 자세한 내용은 다음 문서를 참조하세요: https://blog.csdn.net/a745233700/article/details/85256818 11.1. 원리: 읽기와 쓰기의 분리는 데이터베이스의 쓰기 작업이 쿼리의 효율성에 영향을 미치는 문제를 해결하며 읽기가 쓰기보다 훨씬 큰 시나리오에 적합합니다. 읽기-쓰기 분리를 실현하는 기본은 마스터-슬레이브 복제를 사용하여 자체 데이터 변경 사항을 슬레이브 데이터베이스 클러스터에 동기화한 다음 마스터 데이터베이스가 쓰기 작업을 처리하는 것입니다. 읽기 작업도 수행), 슬레이브 데이터베이스가 읽기 작업 처리를 담당하므로 쓰기 작업을 수행할 수 없습니다. 그리고 압박 상황에 따라 여러 슬레이브 데이터베이스를 배포하여 읽기 작업 속도를 높이고 기본 데이터베이스에 대한 부담을 줄이며 시스템의 전반적인 성능을 향상시킬 수 있습니다. 11.2 읽기 및 쓰기 분리가 성능을 향상시키는 이유: 11.3.Mysql 읽기 및 쓰기 구현 방법: 읽기와 쓰기의 분리로 데이터베이스 읽기 부담이 해결됩니다. 및 쓰기 작업은 데이터베이스의 저장 공간을 분산시키지 않습니다. 압력, 하위 데이터베이스 및 하위 테이블을 사용하면 데이터베이스의 저장 병목 현상을 해결하고 데이터베이스의 쿼리 효율성을 향상시킬 수 있습니다. 12.1. 수직 분할: (1) 수직 테이블 파티셔닝: 테이블을 필드에 따라 여러 테이블로 나누고 각 테이블은 필드의 일부를 저장합니다. 일반적으로 자주 사용되는 필드는 한 테이블에 배치되고, 덜 자주 사용되는 필드는 다른 테이블에 배치됩니다. 장점: (1) IO 경쟁을 피하고 테이블이 잠길 확률을 줄입니다. 큰 필드는 덜 효율적이기 때문에 첫째, 큰 필드는 더 많은 공간을 차지하고 단일 페이지에 저장되는 행 수가 줄어들어 IO 작업이 증가하고 둘째, 데이터 양이 크고 시간이 오래 걸립니다. 읽기. (2)는 인기 있는 데이터의 쿼리 효율성을 더 향상시킬 수 있습니다. (2) 수직 데이터베이스 분할: 서로 다른 비즈니스 모듈에 따라 테이블을 서로 다른 데이터베이스로 분할합니다. 이는 비즈니스 간 결합도가 매우 낮고 비즈니스 로직이 명확한 시스템에 적합합니다. 장점: ( 3) 수직 분할 (서브 데이터베이스, 서브 테이블)의 단점: 12.2 , 가로 분할: (1) 수평 테이블 분할: 동일한 데이터베이스에서 특정 규칙에 따라 동일한 테이블의 데이터를 여러 테이블로 분할합니다. 장점: (2) 수평 데이터베이스 분할: 동일한 테이블의 데이터를 표준에 따라 분할합니다. 특정 규칙을 다른 데이터베이스에 적용할 수 있으며, 다른 데이터베이스를 다른 서버에 배치할 수 있습니다. 장점: (3) 수평 분할의 단점(테이블 및 데이터베이스): 12.3. 하위 데이터베이스 및 하위 테이블 문제에 대한 해결책: (1) 트랜잭션 문제: ① 옵션 1: 분산 트랜잭션 사용: ② 옵션 2: 프로그램과 데이터베이스가 공동으로 구현을 제어합니다. 원칙은 여러 데이터베이스에 걸친 분산 트랜잭션을 단일 데이터베이스에만 존재하는 여러 개의 작은 트랜잭션으로 분해하고 각 작은 트랜잭션을 전체적으로 제어하도록 애플리케이션에 맡기는 것입니다. 거래. (2) 교차 노드 조인 문제: 이 문제를 해결하는 일반적인 방법은 두 개의 쿼리로 구현하는 것입니다. 첫 번째 쿼리의 결과 집합에서 관련 데이터의 ID를 찾고 실행합니다. 이 ID를 기반으로 하는 두 번째 쿼리 관련 데이터를 가져오기 위해 두 번째 쿼리를 요청합니다. (3) Cross-node count, order by, group by, paging, aggregation 기능 문제: 이러한 문제는 전체 데이터 수집을 기반으로 계산이 필요하기 때문입니다. 대부분의 에이전트는 병합 작업을 자동으로 처리하지 않습니다. 이 솔루션은 각 노드에서 결과를 얻은 다음 애플리케이션 측에서 병합합니다. 조인과 달리 각 노드의 쿼리를 병렬로 실행할 수 있기 때문에 하나의 큰 테이블보다 속도가 훨씬 빠릅니다. 그러나 결과 집합이 크면 애플리케이션 메모리 소비가 문제가 됩니다. 12.4. 데이터베이스를 테이블로 나눈 후 ID 키를 어떻게 처리합니까? 데이터베이스를 테이블로 분할한 후에는 각 테이블의 ID가 1부터 시작할 수 없으므로 글로벌 ID를 설정하는 방법은 주로 다음과 같습니다. (1) UUID: (2) 데이터베이스 자동 증가 ID: 데이터베이스를 테이블로 나눈 후 데이터베이스 자동 증가 ID를 사용하려면 서비스가 요청을 받을 때마다 기본 키 생성 전용 라이브러리가 필요합니다. 먼저 이 라이브러리에 데이터의 경우 데이터베이스에 의해 자동으로 증가되는 ID를 얻고 이 ID를 사용하여 하위 데이터베이스 및 하위 테이블에 데이터를 씁니다. (3) Redis 생성 ID: (4) 트위터의 눈송이 알고리즘: 64비트 길이의 ID로, 이 중 1비트는 사용되지 않고 41비트는 밀리초로 사용되며 10비트는 작업 머신 ID로 사용되며 12비트는 일련 번호로 사용됩니다. (5) Meituan의 Leaf 분산 ID 생성 시스템, Meituan-Dianping 분산 ID 생성 시스템: 파티셔닝은 특정 규칙에 따라 테이블 데이터를 다른 위치에 저장하는 것입니다. , 테이블의 데이터 파일을 여러 개의 작은 블록으로 분할합니다. 데이터를 쿼리할 때는 데이터가 어느 영역에 저장되어 있는지만 알고 해당 영역에 직접 쿼리할 필요가 없습니다. 쿼리 성능을 향상시킵니다. 동시에, 테이블 데이터가 특히 크고 하나의 디스크에 들어갈 수 없는 경우 데이터를 다른 디스크에 할당하여 스토리지 병목 현상 문제를 해결할 수도 있습니다. 여러 디스크를 사용하면 디스크의 IO 효율성을 향상시킬 수 있습니다. 데이터베이스의 성능. 분할된 테이블을 사용하는 경우 파티션 필드는 기본 키 또는 고유 인덱스에 배치되어야 하며 테이블당 최대 파티션 수는 1024입니다. 일반적인 파티션 유형은 범위 파티션, 목록 파티션, 해시 파티션입니다. , 키 파티션, (1) 테이블 파티셔닝의 장점: ① 확장성: ② 데이터베이스 성능 향상: ③ 편리한 데이터 운영 및 유지 관리 : (1) 자동 증가 ID: 자동 증가 ID 사용의 장점: 자체 증가 ID 사용의 단점: (2) UUID: 범용 고유 식별 코드 , UUID는 현재 시간, 카운터, 하드웨어 식별자 등의 데이터를 계산하여 생성됩니다. UUID 사용의 장점: UUID 사용의 단점: 일반적인 상황에서 MySQL은 자동 증가 ID 사용을 권장합니다. MySQL의 InnoDB 스토리지 엔진에서는 기본 키 인덱스가 클러스터형 인덱스이고 기본 키 인덱스의 B+ 트리 리프 노드에 기본 키가 저장되기 때문입니다. 기본 키 인덱스가 자동 증분 ID인 경우 순서대로만 정렬하면 됩니다. UUID인 경우 ID가 무작위로 생성되므로 데이터 이동 중에 많은 양의 데이터가 이동하게 됩니다. 삽입으로 인해 대량의 메모리 조각화가 발생하여 삽입 성능이 저하됩니다. 뷰는 하나 이상의 테이블(또는 뷰)에서 파생된 테이블이며 해당 콘텐츠는 쿼리로 정의됩니다. 뷰는 가상 테이블로, 뷰에 대한 정의만 데이터베이스에 저장되며 뷰에 해당하는 데이터는 저장되지 않습니다. 보기. 뷰는 기본 테이블 위에 구축된 테이블이라고 할 수 있으며, 그 구조와 내용은 기본 테이블에서 나오며 기본 테이블의 존재를 기반으로 존재합니다. 뷰는 하나의 기본 테이블 또는 여러 기본 테이블에 해당할 수 있습니다. 뷰는 논리적 의미에서 설정된 기본 테이블과 새로운 관계의 추상화입니다. (1) 뷰의 장점: (2) 뷰의 단점: SQL 문을 먼저 컴파일한 다음 실행해야 하며, 저장 프로시저는 특정 기능을 완료하기 위한 SQL 문 집합입니다. 사용자는 프로시저 이름과 주어진 인수를 사용하여 저장소를 호출할 수 있습니다. 프로그램을 사용하여 데이터베이스 운영을 위한 복잡한 논리를 구현할 수도 있는데 왜 저장 프로시저가 필요한가요? 주된 이유는 프로그램을 사용하여 API를 호출하는 효율성이 상대적으로 느리기 때문입니다. 애플리케이션이 실행을 위해 SQL 문을 MYSQL 엔진에 넘겨야 작업을 직접 수행하는 것이 좋습니다. 그것은 가장 능숙하고 완료할 수 있는 능력입니다. 저장 프로시저의 장점: 트리거는 트리거가 위치한 테이블에서 지정된 이벤트가 발생하고 정의된 조건이 충족될 때 정의된 문 집합입니다. 트리거가 실행됩니다. 데이터 무결성을 보장하기 위해 데이터베이스 측에 트리거 기능을 적용할 수 있습니다. 트리거는 호출을 사용하여 호출해야 하는 특수 저장 프로시저이지만, 트리거는 호출이나 수동 호출을 사용할 필요가 없다는 점에서 다릅니다. 특정 테이블에 데이터를 삽입하거나 삭제하거나 수정할 때 실행이 발생합니다. 데이터베이스 자체의 표준 기능보다 더 정교하고 복잡한 데이터 제어 기능을 갖추고 있습니다. 커서는 수영의 식별자이며 포인터 역할을 할 수 있습니다. 커서는 쿼리 데이터베이스에서 반환된 결과 집합의 모든 레코드를 탐색하는 데 사용할 수 있습니다. 즉, 해당 작업을 수행하기 위해 한 번에 한 행의 데이터만 가리키고 검색할 수 있습니다. 커서를 사용하지 않을 때는 누군가가 한꺼번에 모든 것을 주고 빼앗아 가는 것과 같습니다. 커서를 사용한 후에는 누군가가 하나씩 주는 것과 같습니다. 이것이 좋은지 아닌지 확인한 다음 스스로 선택하십시오. 추천 학습: mysql 비디오 튜토리얼
7. 구조 최적화:
8. 데이터베이스 매개변수 최적화:
9. explain의 실행 계획:
다른 id 값: id 값이 클수록 우선 순위가 높아지고 더 빨리 실행됩니다.
(2) select_type : 일반 질의, 결합 질의, 하위 질의 등 복잡한 질의를 구별하기 위해 주로 사용되는 질의 유형 system: 테이블에 단 하나의 데이터 일치(시스템 테이블과 동일)가 있으며 이는 const 유형의 특수한 경우로 간주될 수 있습니다.
(5) available_keys: 쿼리 중에 사용할 수 있는 인덱스색인 사용: 포함 색인 사용
10. MySQL 마스터-슬레이브 복제:
11 읽기 및 쓰기 분리:
12. 세로 하위 테이블, 세로 하위 데이터베이스, 가로 하위 테이블, 가로 하위 데이터베이스
13. 파티셔닝:
14. 일반적으로 자동 증가 ID 또는 UUID가 기본 키로 사용됩니까?
15. 뷰:
16. 저장 프로시저 절차:
17. 트리거:
18. 커서:
위 내용은 MySQL 데이터베이스에 대한 일반적인 면접 질문을 요약하고 정리합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!