답변이 포함된 MySQL 인터뷰 질문 - 2019

기술의 발전과 발전으로 인해 면접관들은 이제 백엔드 개발 포지션인 만큼 면접 대상자에 대한 요구사항도 점점 더 높아지고 있습니다. 면접은 당연히 데이터베이스 관련 지식을 묻게 되는데, 현재 가장 인기 있는 무료 관계형 데이터베이스 관리 기술은 mysql이다. 그럼 이제 몇 가지 면접 질문과 답변을 모아봤습니다. 살펴보겠습니다.

추천 튜토리얼: MySQL 입문 동영상

1. 기본 키 슈퍼키 후보 키 외래 키

primary 키 :

저장된 데이터 객체를 고유하고 완전하게 식별하는 데이터베이스 테이블의 데이터 열 또는 속성의 조합입니다. 데이터 열에는 기본 키가 하나만 있을 수 있으며 기본 키의 값은 누락될 수 없습니다. 즉, null이 될 수 없습니다.

슈퍼 키:

에서 요소를 고유하게 식별할 수 있습니다. 관계 그룹의 속성 집합을 관계형 스키마의 슈퍼키라고 합니다. 하나의 속성을 슈퍼 키로 사용할 수 있으며 여러 속성을 결합하여 슈퍼 키로 사용할 수도 있습니다. 슈퍼키에는 후보키와 기본키가 있습니다.

후보 키:

은 최소 슈퍼키입니다. , 중복 요소에 대한 슈퍼키가 없습니다.

외래 키:

이 다른 테이블에 존재합니다. 기본 키 테이블의 키를 이 테이블의 외래 키라고 합니다.

2. 데이터베이스 트랜잭션의 4가지 특징과 의미

4가지 데이터베이스 트랜잭션 트랜잭션의 올바른 실행을 위한 기본 요소입니다. ACID, 원자성, 대응, 격리, 내구성.

원자성: 전체 트랜잭션의 모든 작업은 완전히 완료되거나 완료되지 않으며, 중간 어딘가에서 정체될 수 없습니다. 링크. 트랜잭션 실행 중 오류가 발생하면 트랜잭션이 실행되지 않았던 것처럼 트랜잭션이 시작되기 전 상태로 롤백됩니다.

일관성: 트랜잭션 시작 전과 트랜잭션 종료 후 데이터베이스의 무결성 제약 조건 파괴되지 않습니다.

격리: 거래가 시스템의 일부인 것처럼 보이도록 격리된 상태에서 트랜잭션을 실행합니다. 주어진 시간에 수행되는 유일한 작업입니다. 두 개의 트랜잭션이 동시에 실행되어 동일한 기능을 수행하는 경우 트랜잭션 격리를 통해 시스템의 각 트랜잭션은 해당 트랜잭션만 시스템을 사용하고 있다고 생각하게 됩니다. 이 속성을 직렬화라고도 합니다. 트랜잭션 작업 간의 혼동을 방지하려면 동일한 데이터에 대해 동시에 하나의 요청만 있도록 요청을 직렬화하거나 역직렬화해야 합니다.

지속성: 트랜잭션이 완료된 후 트랜잭션으로 인해 데이터베이스에 적용된 변경 사항은 다음과 같습니다. 지속성은 데이터베이스에 저장되며 롤백되지 않습니다.

3 뷰의 역할을 변경할 수 있나요?

뷰는 데이터가 포함된 테이블과 달리 사용 시 데이터를 동적으로 검색하는 쿼리만 포함합니다. 열 또는 데이터. 뷰를 사용하면 복잡한 SQL 작업을 단순화하고 특정 세부 정보를 숨기고 데이터를 보호할 수 있습니다. 뷰가 생성되면 테이블과 동일한 방식으로 활용할 수 있습니다.

뷰를 인덱싱할 수 없으며 관련 트리거 또는 기본값을 가질 수도 없습니다. 뷰 자체에 order by가 있는 경우 view by order가 다시 덮어쓰여집니다. .

뷰 생성: Distinct Union과 같은 쿼리 그룹화 집계 기능으로 뷰 XXX를 생성하지만 뷰를 업데이트하면 기본 테이블이 업데이트됩니다. 뷰는 주로 업데이트가 아닌 검색을 단순화하고 데이터를 보호하는 데 사용되며 대부분의 뷰는 업데이트할 수 없습니다.

4 삭제, 삭제 및 자르기의 차이점

drop 테이블을 직접 삭제합니다. Truncate는 테이블의 데이터를 삭제합니다. 다시 삽입하면 ID가 1에서 자동으로 증가하고 delete는 테이블의 데이터를 삭제할 수 있습니다.

　　 (1) DELETE 문에 의한 삭제 과정은 테이블에서 한 행씩 삭제하는 동시에 해당 행의 삭제 작업은 롤백 작업을 위한 트랜잭션 기록으로 로그에 저장된다. TRUNCATE TABLE은 테이블의 모든 데이터를 한꺼번에 삭제하며, 개별 삭제 작업 기록을 로그에 기록하지 않습니다. 삭제된 행은 복구할 수 없습니다. 그리고 삭제 프로세스 중에는 테이블과 관련된 삭제 트리거가 활성화되지 않습니다. 실행 속도가 빠릅니다.

　 (2) 테이블과 인덱스가 차지하는 공간. 테이블이 TRUNCATE되면 테이블과 인덱스가 차지하는 공간은 원래 크기로 복원되고, DELETE 작업은 테이블이나 인덱스가 차지하는 공간을 줄이지 않습니다. drop 문은 테이블이 차지하는 모든 공간을 해제합니다.

　　 (3) 일반적으로 drop > truncate > delete

　 (4) 적용 범위. TRUNCATE는 TABLE에만 사용할 수 있고, DELETE는 테이블과 뷰만 사용할 수 있습니다

　　 (5) TRUNCATE와 DELETE는 데이터만 삭제하고, DROP은 테이블 전체(구조 및 데이터)를 삭제합니다.

　　 (6) where 없이 자르고 삭제: 데이터만 삭제하고 테이블의 구조(정의)는 삭제하지 않습니다. drop 문은 테이블 구조가 의존하는 제약 조건(constrain), 트리거(trigger) 인덱스를 삭제합니다. on ( index); 테이블에 의존하는 저장 프로시저/함수는 유지되지만 해당 상태는 유효하지 않습니다.

　　 (7) 삭제 문은 DML(데이터 유지 언어)입니다. 이 작업은 롤백 세그먼트에 배치되며 트랜잭션이 제출된 후에만 적용됩니다. 해당 트리거가 있으면 실행 중에 트리거됩니다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ　　8) 자르기 및 삭제는 DLL(데이터 정의 언어)이며 작업은 즉시 적용되며 원본 데이터는 롤백 세그먼트에 배치되지 않으며 롤백할 수 없습니다.　　　　　　　　　　　　　　　　　　　　 9) ? 일부 데이터 행을 삭제하려면 삭제를 사용하고 영향 범위를 제한할 위치와 결합하세요. 롤백 세그먼트는 충분히 커야 합니다. 테이블을 삭제하려면 drop을 사용하고, 테이블을 유지하지만 테이블의 데이터를 삭제하려면 트랜잭션과 관련이 없는 경우 truncate를 사용합니다. 거래와 관련이 있거나 교사가 트리거를 실행하려는 경우에도 삭제를 사용하세요.

　　　(10) Truncate table 테이블 이름은 다음과 같은 이유로 빠르고 효율적입니다. truncate table은 WHERE 절이 없는 DELETE 문과 기능적으로 동일합니다. 둘 다 테이블의 모든 행을 삭제합니다. 그러나 TRUNCATE TABLE은 DELETE보다 빠르며 시스템 및 트랜잭션 로그 리소스를 더 적게 사용합니다. DELETE 문은 한 번에 한 행을 삭제하고 삭제된 각 행에 대한 항목을 트랜잭션 로그에 기록합니다. TRUNCATE TABLE은 테이블 데이터를 저장하는 데 사용된 데이터 페이지를 해제하여 데이터를 삭제하고, 해제된 페이지만 트랜잭션 로그에 기록합니다.

　　 (11) TRUNCATE TABLE은 테이블의 모든 행을 삭제하지만 테이블 구조와 해당 열, 제약 조건, 인덱스 등은 변경되지 않은 상태로 유지됩니다. 새 행을 식별하는 데 사용되는 개수는 해당 열의 시드로 재설정됩니다. ID 개수 값을 유지하려면 대신 DELETE를 사용하세요. 테이블 정의와 해당 데이터를 삭제하려면 DROP TABLE 문을 사용하세요.

　　 (12) FOREIGN KEY 제약 조건이 참조하는 테이블의 경우 TRUNCATE TABLE을 사용할 수 없으며 WHERE 절이 없는 DELETE 문을 사용해야 합니다. TRUNCATE TABLE은 로그되지 않으므로 트리거를 활성화할 수 없습니다.

5. 인덱스의 작동 원리 및 유형

　

데이터베이스 인덱스는 데이터베이스 테이블의 데이터를 빠르게 쿼리하고 업데이트하는 데 도움이 되는 데이터베이스 관리 시스템의 정렬된 데이터 구조입니다. 인덱스 구현은 일반적으로 B-트리와 그 변형 B+-트리를 사용합니다.

데이터베이스 시스템은 데이터 외에도 특정 검색 알고리즘을 만족하는 데이터 구조를 유지하므로 이러한 데이터 구조는 어떤 방식으로든 데이터를 참조(지시)하므로 이러한 데이터 구조에서 고급 검색 알고리즘을 구현할 수 있습니다. 이 데이터 구조는 인덱스입니다.

테이블에 대한 인덱스 설정에는 비용이 따릅니다. 첫째, 데이터베이스의 저장 공간이 늘어나고, 둘째, 데이터를 삽입하고 수정하는 데 더 많은 시간이 걸립니다(인덱스도 그에 따라 변경되기 때문입니다).

　사진은 가능한 인덱싱 방법을 보여줍니다. 왼쪽에는 총 2개의 열과 7개의 레코드가 있는 데이터 테이블이 있습니다. 가장 왼쪽은 데이터 레코드의 물리적 주소입니다(논리적으로 인접한 레코드가 디스크에서 반드시 물리적으로 인접한 것은 아닙니다). Col2의 검색 속도를 높이기 위해 오른쪽에 표시된 것처럼 이진 검색 트리를 유지할 수 있습니다. 각 노드에는 해당 데이터 레코드의 물리적 주소에 대한 포인터와 인덱스 키 값이 포함되어 있습니다. O(log2n)의 이진 검색 복잡도 내에서 해당 데이터를 얻습니다.

　인덱스를 생성하면 시스템 성능이 크게 향상될 수 있습니다.

먼저 고유 인덱스를 생성하면 데이터베이스 테이블의 각 데이터 행에 대한 고유성을 보장할 수 있습니다.

둘째, 데이터 검색 속도를 크게 높일 수 있는데, 이는 인덱스를 생성하는 주된 이유이기도 합니다.

　셋째, 테이블과 테이블 간의 연결 속도를 높일 수 있는데, 이는 특히 데이터의 참조 무결성을 달성하는 데 의미가 있습니다.

　넷째, 데이터 검색을 위해 그룹화 및 정렬 절을 사용하면 쿼리에서 그룹화 및 정렬하는 시간도 크게 줄일 수 있습니다.

다섯째, 인덱스를 사용하면 쿼리 프로세스 중에 최적화 숨기기를 사용하여 시스템 성능을 향상시킬 수 있습니다.

누군가 다음과 같이 질문할 수 있습니다. 인덱스를 추가하면 많은 이점이 있는데 테이블의 모든 열에 대해 인덱스를 생성해 보는 것은 어떨까요? 왜냐하면 인덱스를 추가하는 것에도 단점이 많기 때문입니다.

먼저 인덱스를 생성하고 유지하는 데 시간이 걸리며, 이 시간은 데이터 양이 늘어날수록 늘어납니다.

둘째, 인덱스는 데이터 테이블이 차지하는 데이터 공간 외에 각 인덱스도 일정량의 물리적 공간을 차지해야 합니다. 더 큰.

셋째, 테이블의 데이터 추가, 삭제, 수정 시 인덱스를 동적으로 유지해야 하므로 데이터 유지 속도가 저하됩니다.

　 인덱스는 데이터베이스 테이블의 특정 열에 구축됩니다. 인덱스를 생성할 때 인덱스를 생성할 수 있는 열과 인덱스를 생성할 수 없는 열을 고려해야 합니다. 일반적으로 인덱스는 이러한 컬럼에 생성되어야 합니다. 자주 검색되는 컬럼에 대해서는 검색 속도를 높이고, 기본 키 역할을 하는 컬럼에 대해서는 검색 속도를 높이고, 컬럼의 고유성을 강화하고 테이블 내 데이터의 배열 구조를 구성합니다. ; 자주 검색되는 열에 사용되며, 이 열은 주로 외래 키이므로 연결 속도를 높일 수 있습니다. 지정된 범위는 연속적입니다. 인덱스가 정렬되었으므로 정렬된 열에 인덱스를 생성해야 합니다. 그러면 쿼리가 인덱스 정렬을 사용하여 정렬 쿼리 시간을 단축할 수 있습니다. 조건 판단 속도를 높이기 위해 WHERE 절에서 자주 사용됩니다.

마찬가지로 일부 열에 대해서는 인덱스를 생성하면 안 됩니다. 일반적으로 이러한 인덱스를 생성해서는 안 되는 컬럼은 다음과 같은 특징을 가지고 있습니다.

먼저, 쿼리에서 거의 사용되거나 참조되지 않는 컬럼에 대해서는 인덱스를 생성하면 안 됩니다. 이는 이러한 열이 거의 사용되지 않기 때문에 인덱싱 여부에 관계없이 쿼리 속도가 향상되지 않기 때문입니다. 반대로, 인덱스 추가로 인해 시스템 유지 속도가 감소하고 필요한 공간이 증가합니다.

둘째, 데이터 값이 적은 열에는 인덱스를 추가하면 안 됩니다. 이는 이러한 컬럼은 인사 테이블의 성별 컬럼과 같이 값이 매우 적기 때문에 질의 결과에서는 결과 세트의 데이터 행이 테이블의 데이터 행 중 큰 부분을 차지하기 때문입니다. 테이블에서 검색해야 할 데이터 행의 비율이 엄청납니다. 인덱스를 늘려도 검색 속도는 크게 향상되지 않습니다.

　셋째, 텍스트, 이미지, 비트 데이터 형식으로 정의된 열에는 인덱스를 추가하면 안 됩니다. 이는 이러한 열의 데이터 볼륨이 상당히 크거나 값이 거의 없기 때문입니다.

　넷째, 수정 성능이 검색 성능보다 훨씬 높을 경우 인덱스를 생성해서는 안 됩니다. 수정 성능과 검색 성능이 서로 상반되기 때문이다. 인덱스를 추가하면 검색 성능은 향상되지만 수정 성능은 저하됩니다. 인덱스를 줄이면 수정 성능이 향상되고 검색 성능이 저하됩니다. 따라서 수정 성능이 검색 성능보다 훨씬 높을 경우에는 인덱스를 생성하지 않아야 합니다.

　데이터베이스 디자이너에서는 데이터베이스의 기능에 따라 고유 인덱스, 기본 키 인덱스, 클러스터형 인덱스의 세 가지 유형의 인덱스를 생성할 수 있습니다.

고유 인덱스

　 고유 인덱스는 두 행이 동일한 인덱스 값을 가질 수 없는 인덱스입니다.

대부분의 데이터베이스는 기존 데이터에 중복된 키 값이 있는 경우 새로 생성된 고유 인덱스를 테이블과 함께 저장하는 것을 허용하지 않습니다. 데이터베이스는 테이블에 중복 키 값을 생성하는 새 데이터 추가를 방지할 수도 있습니다. 예를 들어, 직원 테이블에 있는 직원의 성(lname)에 대해 고유 인덱스가 생성되면 두 명의 직원이 동일한 성을 가질 수 없습니다. 기본 키 인덱스 데이터베이스 테이블에는 값이 테이블의 각 행을 고유하게 식별하는 열 또는 열 조합이 있는 경우가 많습니다. 이 열을 테이블의 기본 키라고 합니다. 데이터베이스 다이어그램에서 테이블에 대한 기본 키를 정의하면 특정 유형의 고유 인덱스인 기본 키 인덱스가 자동으로 생성됩니다. 인덱스에서는 기본 키의 각 값이 고유해야 합니다. 또한 쿼리에 기본 키 인덱스가 사용될 때 데이터에 빠르게 액세스할 수 있습니다. 클러스터형 인덱스 클러스터형 인덱스에서 테이블 행의 물리적 순서는 키 값의 논리적(인덱스) 순서와 동일합니다. 테이블에는 클러스터형 인덱스가 하나만 포함될 수 있습니다.

　 인덱스가 클러스터형 인덱스가 아닌 경우 테이블 행의 물리적 순서는 키 값의 논리적 순서와 일치하지 않습니다. 클러스터형 인덱스는 일반적으로 비클러스터형 인덱스보다 더 빠른 데이터 액세스를 제공합니다.

지역성 원칙 및 디스크 미리 읽기

저장 매체의 특성으로 인해 디스크 자체는 기계적 이동 비용, 액세스 속도에 비해 액세스 속도가 훨씬 느립니다. 디스크의 속도가 주 메모리의 속도보다 빠른 경우가 많으므로 효율성을 높이려면 디스크 I/O를 최소화해야 합니다. 이 목표를 달성하기 위해 디스크는 엄격하게 요구에 따라 읽는 것이 아니라 매번 미리 읽는 경우가 많습니다. 1바이트만 필요하더라도 디스크는 이 위치에서 시작하여 일정 길이의 데이터를 순차적으로 읽어옵니다. 메모리. 이에 대한 이론적 근거는 컴퓨터 과학에서 잘 알려진 지역성 원리입니다. 즉, 데이터 조각이 사용될 때 일반적으로 근처의 데이터가 즉시 사용됩니다. 프로그램 실행 중에 필요한 데이터는 일반적으로 집중되어 있습니다.

디스크 순차 읽기는 매우 효율적이므로(탐색 시간이 필요하지 않고 회전 시간도 거의 없음) 미리 읽기는 지역성이 있는 프로그램의 I/O 효율성을 향상시킬 수 있습니다.

　사전 읽기 길이는 일반적으로 페이지의 정수배입니다. 페이지는 컴퓨터 관리 메모리의 논리적 블록입니다. 하드웨어 및 운영 체제는 주 메모리와 디스크 저장 영역을 동일한 크기의 연속된 블록으로 나누는 경우가 많습니다(많은 운영 체제에서 페이지 크기는 일반적으로 4k입니다). 메인 메모리와 디스크는 페이지 단위로 데이터를 교환합니다. 프로그램이 읽을 데이터가 메인 메모리에 없으면 페이지 폴트 예외가 발생합니다. 이때 시스템은 읽기 신호를 디스크에 보내고 디스크는 데이터의 시작 위치를 찾습니다. 하나 이상의 페이지를 거꾸로 읽습니다. 메모리에 로드한 다음 비정상적으로 반환되고 프로그램이 계속 실행됩니다.

B-/+Tree 지수의 성능 분석

이제 드디어 B-/+Tree 지수의 성능을 분석할 수 있습니다.

위에서 언급했듯이 디스크 I/O 개수는 일반적으로 인덱스 구조의 품질을 평가하는 데 사용됩니다. B-Tree 분석부터 시작해 보겠습니다. B-Tree의 정의에 따르면 한 번의 검색을 위해 최대 h개의 노드를 방문해야 함을 알 수 있습니다. 데이터베이스 시스템의 설계자는 디스크 미리 읽기 원칙을 교묘하게 활용하여 노드의 크기를 한 페이지와 동일하게 설정하여 각 노드가 단 하나의 I/O로 완전히 로드될 수 있도록 했습니다. 이 목표를 달성하려면 B-Tree의 실제 구현에 다음 기술을 사용해야 합니다.

새 노드가 생성될 때마다 공간 페이지가 직접 적용됩니다. 또한 컴퓨터 스토리지 할당은 페이지별로 정렬됩니다. 즉, 하나의 노드에 하나의 I/O만 필요합니다.

　B-Tree에서 검색하려면 최대 h-1 I/O(루트 노드 상주 메모리)가 필요하며 점근적 복잡도는 O(h)=O(logdN)입니다. 일반적인 실제 적용에서, 아웃 차수 d는 ​​매우 큰 숫자(보통 100 이상)이므로 h는 매우 작습니다(보통 3 이하).

레드-블랙 트리 구조의 경우 h는 분명히 훨씬 더 깊습니다. 논리적으로 가까운 노드(부모와 자식)가 물리적으로 멀리 떨어져 있을 수 있으므로 지역성을 활용할 수 없으므로 레드-블랙 트리의 I/O 점근적 복잡도도 O(h)이며 효율성은 분명히 B-트리.

정리하자면, B-Tree를 인덱스 구조로 사용하는 것은 매우 효율적입니다.

6. 연결 유형

쿼리 분석기에서 실행:
--테이블 table1, table2 만들기:

create table table1(id int,name varchar(10))
create table table2(id int,score int)
insert into table1 select 1,'lee'
insert into table1 select 2,'zhang'
insert into table1 select 4,'wang'
insert into table2 select 1,90
insert into table2 select 2,100
insert into table2 select 3,70

테이블로

-------------------------------------------------
table1 | table2 |
-------------------------------------------------
id name |id score |
1 lee |1 90|
2 zhang| 2 100|
4 wang| 3 70|
-------------------------------------------------

다음 내용은 모두 쿼리 분석기에서 실행
1. 외부 조인
1. 개념: 왼쪽 외부 조인, 오른쪽 외부 조인 또는 완전 외부 조인 포함

2.左连接：left join 或 left outer join

　　(1)左向外联接的结果集包括 LEFT OUTER 子句中指定的左表的所有行，而不仅仅是联接列所匹配的行。如果左表的某行在右表中没有匹配行，则在相关联的结果集行中右表的所有选择列表列均为空值(null)。
　　(2)sql 语句

select * from table1 left join table2 on table1.id=table2.id

-------------结果-------------
idnameidscore
------------------------------
1lee190
2zhang2100
4wangNULLNULL
------------------------------

注释：包含table1的所有子句，根据指定条件返回table2相应的字段，不符合的以null显示

3.右连接：right join 或 right outer join

　　(1)右向外联接是左向外联接的反向联接。将返回右表的所有行。如果右表的某行在左表中没有匹配行，则将为左表返回空值。

　　(2)sql 语句

select * from table1 right join table2 on table1.id=table2.id

-------------结果-------------
idnameidscore
------------------------------
1lee190
2zhang2100
NULLNULL370
------------------------------

注释：包含table2的所有子句，根据指定条件返回table1相应的字段，不符合的以null显示

4.完整外部联接:full join 或 full outer join

　　(1)完整外部联接返回左表和右表中的所有行。当某行在另一个表中没有匹配行时，则另一个表的选择列表列包含空值。如果表之间有匹配行，则整个结果集行包含基表的数据值。

　　(2)sql 语句

select * from table1 full join table2 on table1.id=table2.id

-------------结果-------------
idnameidscore
------------------------------
1lee190
2zhang2100
4wangNULLNULL
NULLNULL370
------------------------------

注释：返回左右连接的和（见上左、右连接）

二、内连接

　　1.概念：内联接是用比较运算符比较要联接列的值的联接

　　2.内连接：join 或 inner join

　　3.sql 语句

select * from table1 join table2 on table1.id=table2.id

-------------结果-------------
idnameidscore
------------------------------
1lee190
2zhang2100
------------------------------

注释：只返回符合条件的table1和table2的列

　　4.等价（与下列执行效果相同）

　　A:select a.*,b.* from table1 a,table2 b where a.id=b.id

　　B:select * from table1 cross join table2 where table1.id=table2.id (注：cross join后加条件只能用where,不能用on)

三、交叉连接(完全)

　　1.概念：没有 WHERE 子句的交叉联接将产生联接所涉及的表的笛卡尔积。第一个表的行数乘以第二个表的行数等于笛卡尔积结果集的大小。（table1和table2交叉连接产生3*3=9条记录）

　　2.交叉连接：cross join (不带条件where...)

　　3.sql语句

select * from table1 cross join table2

-------------结果-------------
idnameidscore
------------------------------
1lee190
2zhang190
4wang190
1lee2100
2zhang2100
4wang2100
1lee370
2zhang370
4wang370
------------------------------

注释：返回3*3=9条记录，即笛卡尔积

　　4.等价（与下列执行效果相同）

　　A:select * from table1,table2

7、数据库范式

　　1） 第一范式（1NF）

　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。

　　2 ）第二范式（2NF）

　　第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。

　　第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

　　3 ）第三范式（3NF）

　　满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。（我的理解是消除冗余）

 8、数据库优化的思路

　　这个我借鉴了慕课上关于数据库优化的课程。

一、SQL语句优化

　　1）应尽量避免在 where 子句中使用!=或a8093152e673feb7aba1828c43532094操作符，否则将引擎放弃使用索引而进行全表扫描。

　　2）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

　　可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

　　3）很多时候用 exists 代替 in 是一个好的选择

　　4）用Where子句替换HAVING 子句 因为HAVING 只会在检索出所有记录之后才对结果集进行过滤

二、索引优化

　　看上文索引

三、数据库结构优化

　　1）范式优化： 比如消除冗余（节省空间。。）

　　 2）反范式优化：比如适当加冗余等（减少join）

　　 3）拆分表： 分区将数据在物理上分隔开，不同分区的数据可以制定保存在处于不同磁盘上的数据文件里。这样，当对这个表进行查询时，只需要在表分区中进行扫描，而不必进行全表扫描，明显缩短了查询时间，另外处于不同磁盘的分区也将对这个表的数据传输分散在不同的磁盘I/O，一个精心设置的分区可以将数据传输对磁盘I/O竞争均匀地分散开。对数据量大的时时表可采取此方法。可按月自动建表分区。
　　4）拆分其实又分垂直拆分和水平拆分： 案例： 简单购物系统暂设涉及如下表： 1.产品表（数据量10w，稳定） 2.订单表（数据量200w，且有增长趋势） 3.用户表 （数据量100w，且有增长趋势） 以mysql为例讲述下水平拆分和垂直拆分，mysql能容忍的数量级在百万静态数据可以到千万 垂直拆分：解决问题：表与表之间的io竞争 不解决问题：单表中数据量增长出现的压力 方案： 把产品表和用户表放到一个server上 订单表单独放到一个server上 水平拆分： 解决问题：单表中数据量增长出现的压力 不解决问题：表与表之间的io争夺

　　方案： 用户表通过性别拆分为男用户表和女用户表 订单表通过已完成和完成中拆分为已完成订单和未完成订单 产品表 未完成订单放一个server上 已完成订单表盒男用户表放一个server上 女用户表放一个server上(女的爱购物 哈哈)

四、服务器硬件优化

　　这个么多花钱咯！

9、存储过程与触发器的区别

　 트리거는 저장 프로시저와 매우 유사합니다. 트리거도 SQL 문 집합입니다. 둘 사이의 유일한 차이점은 트리거가 EXECUTE 문으로 호출될 수 없지만 사용자가 Transact-SQL을 실행할 때 자동으로 트리거(활성화)된다는 것입니다. 성명. 트리거는 지정된 테이블의 데이터가 수정될 때 실행되는 저장 프로시저입니다. 트리거는 서로 다른 테이블에 있는 논리적으로 관련된 데이터의 참조 무결성과 일관성을 강화하기 위해 생성되는 경우가 많습니다. 사용자는 트리거를 우회할 수 없으므로 트리거를 사용하여 복잡한 비즈니스 규칙을 시행하여 데이터 무결성을 보장할 수 있습니다. 트리거는 저장 프로시저와 달리 주로 이벤트 실행 트리거를 통해 실행되지만 저장 프로시저는 저장 프로시저 이름을 통해 직접 호출할 수 있습니다. 특정 테이블에 대해 UPDATE, INSERT, DELETE 등의 작업이 수행되면 SQLSERVER는 트리거에 의해 정의된 SQL 문을 자동으로 실행하므로 데이터 처리가 이러한 SQL 문에 정의된 규칙을 준수해야 합니다.

원본 주소: https://www.cnblogs.com/frankielf0921/p/5930743.html

위 내용은 답변이 포함된 MySQL 인터뷰 질문 - 2019의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!