다음은 인터뷰나 스터디에서 자주 접하게 되는 MySQL 질문들입니다. SQL 문 최적화 예: 1) where 절에 != 또는 연산자를 사용하지 마십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행합니다. 2) where 절에 있는 필드의 null 값을 판단하지 마십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 다음과 같이 전체 테이블 스캔을 수행합니다. select id from t where num is null
#🎜 🎜##🎜 🎜#【관련 주제 추천 :mysql 면접 질문(2020)】 1. 기본 키, 슈퍼 키, 후보 키, 외래 키
기본 키:데이터베이스의 데이터 열 저장된 데이터 개체 또는 속성 조합을 고유하고 완전하게 식별하는 테이블입니다.
데이터 열에는 기본 키가 하나만 있을 수 있으며기본 키의 값은 누락될 수 없습니다. 즉, null이 될 수 없습니다.
슈퍼 키:관계에서 튜플을 고유하게 식별할 수 있는 속성 집합을 관계형 스키마의 슈퍼 키라고 합니다. 하나의 속성을 슈퍼 키로 사용할 수 있으며 여러 속성을 결합하여 슈퍼 키로 사용할 수도 있습니다.
슈퍼 키에는 후보 키와 기본 키가 포함됩니다.후보 키:
은
최소 슈퍼키입니다. 즉, 없습니다. 중복 요소 슈퍼 키.
외래 키:한 테이블에 존재
다른 테이블의 기본 키를 이 테이블의 외래 키라고 합니다. 열쇠. 2. 데이터베이스 트랜잭션의 4가지 특징과 의미
atomicity
: 전체 트랜잭션의 모든 작업은 완료되거나 완료되지 않으며 일부 중간 링크에서 정체될 수 없습니다. 트랜잭션 실행 중 오류가 발생하면 트랜잭션이 실행되지 않았던 것처럼 트랜잭션이 시작되기 전 상태로 롤백됩니다. Consistency
: 트랜잭션이 시작되기 전과 트랜잭션이 끝난 후에도 데이터베이스의 무결성 제약 조건을 위반하지 않습니다. isolation
: 격리 상태는 주어진 시간에 시스템에서 수행되는 유일한 작업인 것처럼 보이도록 트랜잭션을 실행합니다. 두 개의 트랜잭션이 동시에 실행되어 동일한 기능을 수행하는 경우 트랜잭션 격리를 통해 시스템의 각 트랜잭션은 해당 트랜잭션만 시스템을 사용하고 있다고 생각하게 됩니다. 이 속성을 직렬화라고도 합니다. 트랜잭션 작업 간의 혼동을 방지하려면 동일한 데이터에 대해 동시에 하나의 요청만 있도록 요청을 직렬화하거나 역직렬화해야 합니다. Persistence
: 트랜잭션이 완료된 후 트랜잭션으로 인해 데이터베이스에 적용된 변경 사항이 데이터베이스에 유지되며 롤백되지 않습니다. 3. 뷰의 역할, 뷰는 바뀔 수 있나요?
뷰 생성: 뷰 생성 업데이트 그러나 뷰는 주로 업데이트가 아닌 검색을 단순화하고 데이터를 보호하는 데 사용되며 대부분의 뷰는 업데이트할 수 없습니다.
4 drop, delete, truncate의 차이점
(6) where 없이 자르고 삭제: 데이터만 삭제하고 테이블의 구조(정의)는 삭제하지 않습니다. drop 문은 테이블 구조가 의존하는 제약 조건(constraint)과 트리거 인덱스를 삭제합니다( index ); 테이블에 의존하는 저장 프로시저/함수는 유지되지만 해당 상태는 유효하지 않습니다.
(7) 삭제 문은 DML(데이터 유지 언어)입니다. 이 작업은 롤백 세그먼트에 배치되며 트랜잭션이 제출된 후에만 적용됩니다. 해당 트리거가 있으면 실행 중에 트리거됩니다.
(8) 자르기 및 삭제는 DLL(데이터 정의 언어)입니다. 작업은 즉시 적용됩니다. 원본 데이터는 롤백 세그먼트에 배치되지 않으며
#🎜🎜 # (9) In 백업이 없는 경우에는 drop 및 truncate를 주의해서 사용하세요. 일부 데이터 행을 삭제하려면 삭제를 사용하고 영향 범위를 제한할 위치와 결합하세요. 롤백 세그먼트는 충분히 커야 합니다. 테이블을 삭제하려면 drop을 사용하고, 테이블을 유지하지만 테이블의 데이터를 삭제하려면 트랜잭션과 관련이 없는 경우 truncate를 사용합니다. 거래와 관련이 있거나 교사가 트리거를 실행하려는 경우에도 삭제를 사용하세요. (10) Truncate table 테이블 이름은 다음과 같은 이유로 빠르고 효율적입니다.truncate table은 WHERE 절이 없는 DELETE 문과 기능적으로 동일합니다. 둘 다 모든 행의 테이블을 삭제합니다. 그러나 TRUNCATE TABLE은 DELETE보다 빠르며 시스템 및 트랜잭션 로그 리소스를 더 적게 사용합니다. DELETE 문은 한 번에 한 행을 삭제하고 삭제된 각 행에 대한 항목을 트랜잭션 로그에 기록합니다. TRUNCATE TABLE은 테이블 데이터를 저장하는 데 사용된 데이터 페이지를 해제하여 데이터를 삭제하고, 해제된 페이지만 트랜잭션 로그에 기록합니다.
Database index은 빠른 쿼리를 지원하기 위한 데이터베이스 관리 시스템의 정렬된 데이터 구조입니다. 데이터베이스 테이블의 데이터를 업데이트합니다. 인덱스 구현은 일반적으로 B-트리와 그 변형 B+트리를 사용합니다.
데이터 외에도 데이터베이스 시스템은 특정 검색 알고리즘을 만족하는 데이터 구조를 유지하므로 이러한 데이터 구조는 어떤 방식으로든 데이터를 참조(지시)하므로 이러한 데이터에 대한 고급 검색이 구현될 수 있습니다. 구조. 이 데이터 구조는 인덱스입니다. 테이블에 인덱스를 설정하려면 비용이 듭니다. 첫째, 데이터베이스의 저장 공간이 늘어나고, 둘째, 데이터를 삽입하고 수정하는 데 더 많은 시간이 걸립니다. 그에 따라 변경됩니다).
n)의 복잡도 내에서 해당 데이터를 이진 검색합니다. 색인을 생성하면 시스템 성능이 크게 향상될 수 있습니다.
첫째, 고유 인덱스를 생성하면 데이터베이스 테이블의 각 데이터 행에 대한 고유성을 보장할 수 있습니다.
둘째, 데이터 검색 속도를 크게 높일 수 있는데, 이는 인덱스를 만드는 주된 이유이기도 합니다.
셋째, 테이블 간의 연결 속도를 높일 수 있는데, 이는 특히 데이터의 참조 무결성을 달성하는 데 의미가 있습니다.
넷째, 데이터 검색을 위해 그룹화 및 정렬 절을 사용하면 쿼리에서 그룹화 및 정렬하는 시간도 크게 줄일 수 있습니다.
다섯째, 인덱스를 사용하면 쿼리 프로세스 중에 최적화 숨기기를 사용하여 시스템 성능을 향상시킬 수 있습니다.
어떤 사람들은 다음과 같이 질문할 수 있습니다. 인덱스를 추가하면 많은 이점이 있는데 테이블의 모든 열에 대해 인덱스를 생성해 보는 것은 어떨까요? 왜냐하면 인덱스를 추가하는 것에도 단점이 많기 때문입니다.
첫째, 인덱스를 생성하고 유지하는 데 시간이 걸리며, 이 시간은 데이터 양이 늘어날수록 늘어납니다.
둘째, 인덱스는 데이터 테이블이 차지하는 데이터 공간 외에 각 인덱스도 일정량의 물리적 공간을 차지해야 합니다. 필요한 공간이 더 커질 것입니다.
셋째, 테이블에 데이터를 추가, 삭제, 수정하는 경우 인덱스를 동적으로 유지해야 하므로 데이터 유지 속도가 떨어집니다.
인덱스는 데이터베이스 테이블의 특정 열에 구축됩니다. 인덱스를 생성할 때 인덱스를 생성할 수 있는 열과 인덱스를 생성할 수 없는 열을 고려해야 합니다. 일반적으로 인덱스는 다음 열에 생성되어야 합니다. 자주 검색되는 열에서는 기본 키 역할을 하는 열에 대한 검색 속도를 높이고 열의 고유성을 강화하며 테이블의 데이터 배열을 구성할 수 있습니다. 조인에 자주 사용되는 열에 인덱스를 생성합니다. 인덱스가 정렬되어 있고 지정된 범위가 연속적이므로 범위를 기준으로 자주 검색해야 하는 열에 인덱스를 생성합니다. ; 자주 정렬해야 하는 열에 인덱스를 생성합니다. 인덱스는 이미 정렬되어 있으므로 쿼리는 인덱스 정렬을 사용하여 정렬 쿼리 시간을 단축할 수 있습니다. 조건 판단을 올려라.
또한 인덱스를 생성하면 안되는 컬럼도 있습니다. 일반적으로 이러한 인덱스를 생성해서는 안 되는 열은 다음과 같은 특징을 가지고 있습니다.
첫째, 쿼리에서 거의 사용되거나 참조되지 않는 열에 대해서는 인덱스를 생성하면 안 됩니다. 이는 이러한 열이 거의 사용되지 않기 때문에 인덱싱 여부에 관계없이 쿼리 속도가 향상되지 않기 때문입니다. 반대로, 인덱스 추가로 인해 시스템 유지 속도가 감소하고 필요한 공간이 증가합니다.
둘째, 데이터 값이 적은 열의 경우 인덱스를 늘리면 안 됩니다. 이는 이러한 컬럼은 인사 테이블의 성별 컬럼과 같이 값이 매우 적기 때문에 질의 결과에서는 결과 세트의 데이터 행이 테이블의 데이터 행 중 큰 부분을 차지하기 때문입니다. 테이블에서 검색해야 할 데이터 행의 비율이 엄청납니다. 인덱스를 늘려도 검색 속도는 크게 향상되지 않습니다.
셋째, 텍스트, 이미지, 비트 데이터 유형으로 정의된 열에는 인덱스를 추가하면 안 됩니다. 이는 이러한 열의 데이터 볼륨이 상당히 크거나 값이 거의 없기 때문입니다.
넷째, 수정 성능이 검색 성능보다 훨씬 높을 경우 인덱스를 생성해서는 안 됩니다. 수정 성능과 검색 성능이 서로 모순이기 때문입니다. 인덱스를 추가하면 검색 성능은 향상되지만 수정 성능은 저하됩니다. 인덱스를 줄이면 수정 성능이 향상되고 검색 성능이 저하됩니다. 따라서 수정 성능이 검색 성능보다 훨씬 높을 경우 인덱스를 생성해서는 안 됩니다.
데이터베이스 기능에 따라 데이터베이스 디자이너에서는 고유 인덱스, 기본 키 인덱스, 클러스터형 인덱스의 세 가지 유형의 인덱스를 생성할 수 있습니다.
고유 인덱스
고유 인덱스는 두 행이 동일한 인덱스 값을 가질 수 없는 인덱스입니다.
대부분의 데이터베이스는 기존 데이터에 중복된 키 값이 있는 경우 새로 생성된 고유 인덱스를 테이블과 함께 저장하는 것을 허용하지 않습니다. 데이터베이스는 테이블에 중복 키 값을 생성하는 새 데이터 추가를 방지할 수도 있습니다. 예를 들어, 직원 테이블에 있는 직원의 성(lname)에 대해 고유 인덱스가 생성되면 두 명의 직원이 동일한 성을 가질 수 없습니다. 기본 키 인덱스 데이터베이스 테이블에는 테이블의 각 행을 고유하게 식별하는 값을 갖는 열 또는 열 조합이 있는 경우가 많습니다. 이 열을 테이블의 기본 키라고 합니다. 데이터베이스 다이어그램에서 테이블에 대한 기본 키를 정의하면 특정 유형의 고유 인덱스인 기본 키 인덱스가 자동으로 생성됩니다. 인덱스에서는 기본 키의 각 값이 고유해야 합니다. 또한 쿼리에 기본 키 인덱스가 사용될 때 데이터에 빠르게 액세스할 수 있습니다. Clustered Index클러스터형 인덱스에서는 테이블 행의 물리적 순서가 키 값의 논리적(인덱스) 순서와 동일합니다. 테이블에는 클러스터형 인덱스가 하나만 포함될 수 있습니다.
인덱스가 클러스터형 인덱스가 아닌 경우 테이블 행의 물리적 순서는 키 값의 논리적 순서와 일치하지 않습니다. 클러스터형 인덱스는 일반적으로 비클러스터형 인덱스에 비해 더 빠른 데이터 액세스를 제공합니다.
저장 매체의 특성으로 인해 디스크 자체는 주 메모리에 비해 액세스 속도가 훨씬 느립니다. 기계적 이동 비용과 함께 디스크의 액세스 속도도 느려지는 경우가 많습니다. 첫째, 효율성을 높이려면 디스크 I/O를 최소화해야 합니다. 이 목표를 달성하기 위해 디스크는 엄격하게 요구에 따라 읽는 것이 아니라 매번 미리 읽는 경우가 많습니다. 1바이트만 필요하더라도 디스크는 이 위치에서 시작하여 일정 길이의 데이터를 순차적으로 읽어옵니다. 메모리. 이에 대한 이론적 근거는 컴퓨터 과학의 유명한 지역성 원리입니다. 데이터 조각을 사용하면 일반적으로 근처에 있는 데이터가 즉시 사용됩니다. 프로그램 실행 중에 필요한 데이터는 일반적으로 집중되어 있습니다.
디스크 순차 읽기는 매우 효율적이므로(탐색 시간이 필요하지 않고 회전 시간이 거의 없음) 미리 읽기는 지역성이 있는 프로그램의 I/O 효율성을 향상시킬 수 있습니다.
미리 읽기 길이는 일반적으로 페이지의 정수배입니다. 페이지는 컴퓨터 관리 메모리의 논리적 블록입니다. 하드웨어 및 운영 체제는 주 메모리와 디스크 저장 영역을 동일한 크기의 연속된 블록으로 나누는 경우가 많습니다(많은 운영 체제에서 페이지 크기는 일반적으로 4k입니다). 메인 메모리와 디스크는 페이지 단위로 데이터를 교환합니다. 프로그램이 읽을 데이터가 메인 메모리에 없으면 페이지 폴트 예외가 발생합니다. 이때 시스템은 읽기 신호를 디스크에 보내고 디스크는 데이터의 시작 위치를 찾습니다. 한 페이지 또는 여러 페이지를 거꾸로 읽어 메모리에 로드한 후 비정상적으로 반환되고 프로그램이 계속 실행됩니다.
이제 드디어 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를 인덱스 구조로 사용하는 것은 매우 효율적입니다.
쿼리 분석기에서 실행:
– 테이블 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 선택 2,'zhang'
insert into table1 선택 4,'wang'
insert into table2 선택 1,90
insert into table2 선택 2,100
insert into table2 선택 3,70
As 표에 나와있습니다
—————————————-
table1 | table2 |
————————————-
id 이름 |id 점수
1 lee |1 90|
2 zhang| 2 100|
4 wang|
———————————————-
다음은 모두 쿼리 분석기에서 실행됩니다
1 . 외부 조인
1. 개념: 왼쪽 외부 조인, 오른쪽 외부 조인 또는 완전 외부 조인 포함
2. 왼쪽 조인: 왼쪽 외부 조인
(1) 왼쪽 외부 조인의 결과 집합에는 다음의 모든 행이 포함됩니다. 조인 열과 일치하는 행뿐만 아니라 절에 지정된 왼쪽 테이블. 왼쪽 테이블의 행에 오른쪽 테이블의 일치하는 행이 없으면 오른쪽 테이블의 모든 선택 목록 열은 연결된 결과 집합 행에서 null이 됩니다.
(2)sql 문
select * from table1 left Join table2 on table1.id=table2.id
————-result————-
idnameidscore
——————————
1lee190
2zhang2100
4wangNULLNULL
——————————
참고: table1의 모든 절을 포함하고, 지정된 조건에 따라 table2의 해당 필드를 반환하며, 호환되지 않는 필드는 null
3으로 표시합니다. 오른쪽 외부 조인 또는 오른쪽 외부 조인
(1) 오른쪽 외부 조인은 왼쪽 외부 조인의 역조인입니다. 오른쪽 테이블의 모든 행이 반환됩니다. 오른쪽 테이블의 행과 왼쪽 테이블의 일치하는 행이 없으면 왼쪽 테이블에 대해 NULL이 반환됩니다.
(2)sql 문
select * from table1 right Join table2 on table1.id=table2.id
————-result————-
idnameidscore
——————————
1lee190
2zhang2100
NULLNULL370
——————————
참고: table2의 모든 절을 포함하고, 지정된 조건에 따라 table1의 해당 필드를 반환하며, 비준수 필드를 null로 표시합니다
4. : 완전 외부 조인 또는 완전 외부 조인
(1) 완전 외부 조인은 왼쪽 테이블과 오른쪽 테이블의 모든 행을 반환합니다. 행에 다른 테이블에 일치하는 행이 없으면 다른 테이블의 선택 목록 열에 Null 값이 포함됩니다. 테이블 간에 일치하는 행이 있는 경우 전체 결과 집합 행에는 기본 테이블의 데이터 값이 포함됩니다.
(2)sql 문
select * from table1 full Join table2 on table1.id=table2.id
————-result————-
idnameidscore
——————————
1lee190
2zhang2100
4wangNULLNULL
NULLNULL370
——————————
참고: 왼쪽 및 오른쪽 조인의 합을 반환합니다(위의 왼쪽 및 오른쪽 조인 참조)
2 개념: 내부 조인. 조인이 사용됩니다 조인할 열의 값을 조인하는 비교 연산자입니다
2. 내부 조인: 조인 또는 내부 조인
3.sql 문
select * from table1 조인 table2 on table1.id=table2. id
————-Result ————-
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 이후에만 사용할 수 있으며에서는 사용할 수 없습니다.)
3 Cross Join
(완료)
1. : WHERE 절이 없는 교차 조인은 관련된 테이블의 조인 데카르트 곱을 생성합니다. 첫 번째 테이블의 행 수에 두 번째 테이블의 행 수를 곱한 값은 데카르트 곱 결과 집합의 크기와 같습니다. (table1과 table2의 교차 조인은 3*3=9개의 레코드를 생성합니다)
2. 교차 조인:
교차 조인(조건 없음...)
3.sql 문
select * from table1 교차 조인 table2
—— ——-결과————-
idnameidscore
——————————
1lee190
2zhang190
4wang190
1lee2100
2zhang2100
4wang2100
1lee370
2zhang370
4wang370
——————— — —
참고: 데카르트 곱인 3*3=9 레코드를 반환합니다
4. 동일합니다(다음 실행 효과와 동일)
A: table1, table2에서 * 선택
1 첫 번째 정규형(1NF)
모든 관계형 데이터베이스에서 첫 번째 정규형(1NF)은 관계형 모델의 기본 요구 사항입니다. 1NF)는 관계형 데이터베이스가 아닙니다.
1NF(첫 번째 정규형)는 데이터베이스 테이블의 각 열이 분할할 수 없는 기본 데이터 항목임을 의미합니다. 즉, 엔터티의 속성은 여러 값을 가질 수 없습니다. 또는 중복된 재산. 중복 특성이 나타나면 새 엔터티를 정의해야 할 수 있습니다. 새 엔터티는 중복 특성으로 구성됩니다. 새 엔터티와 원래 엔터티 사이에는 일대다 관계가 있습니다. 첫 번째 정규형(1NF)에서 테이블의 각 행에는 하나의 인스턴스에 대한 정보만 포함됩니다. 간단히 말해서, 첫 번째 정규형은 반복되지 않는 열입니다.
2 제2정규형(2NF)
제2정규형(2NF)은 제1정규형(1NF)을 기반으로 성립되는데, 즉 제2정규형(2NF)을 만족하려면 반드시 먼저 첫 번째 정규형( 1NF)을 충족합니다. 2NF(두 번째 정규형)에서는 데이터베이스 테이블의 각 인스턴스나 행을 고유하게 구별할 수 있어야 합니다. 차별화를 위해서는 일반적으로 각 인스턴스의 고유 식별자를 저장하기 위해 테이블에 열을 추가해야 합니다. 이 고유한 속성 열을 기본 키, 기본 키 또는 기본 키라고 합니다.
두 번째 정규형(2NF)에서는 엔터티의 속성이 기본 키에 완전히 의존해야 합니다. 소위 완전한 종속성은 기본 키의 일부에만 의존하는 속성이 있을 수 없음을 의미하며, 이 속성과 기본 키의 이 부분을 분리하여 새로운 엔터티를 형성해야 합니다. 원래 엔터티와 일대다 관계. 차별화를 위해서는 일반적으로 각 인스턴스의 고유 식별자를 저장하기 위해 테이블에 열을 추가해야 합니다. 즉, 두 번째 정규형은 기본이 아닌 속성이 기본 키워드에 부분적으로 의존하지 않는다는 것입니다.
3 제3정규형(3NF)
제3정규형(3NF)을 만족하려면 먼저 제2정규형(2NF)을 만족해야 합니다. 간단히 말해서, 3NF(제3정규형)에서는 데이터베이스 테이블에 다른 테이블에 이미 포함되어 있는 기본 키가 아닌 정보가 포함되어 있지 않아야 합니다. 예를 들어, 부서 정보 테이블이 있는데, 각 부서에는 부서 번호(dept_id), 부서 이름, 부서 프로필 및 기타 정보가 있습니다. 그러면 사원정보 테이블에 부서번호가 등록된 후에는 부서명, 부서 프로필, 기타 부서 관련 정보를 사원정보 테이블에 추가할 수 없습니다. 부서정보 테이블이 존재하지 않는 경우에는 제3정규형(3NF)에 따라 구성해야 하며, 그렇지 않으면 데이터 중복이 많이 발생한다. 간단히 말해서, 세 번째 정규형은 속성이 기본이 아닌 다른 속성에 의존하지 않는다는 것입니다. (내 이해는 중복성을 제거하는 것입니다)
데이터베이스 최적화에 관한 MOOC에서 이 강좌를 빌렸습니다.
1) where 절에 != 또는 연산자를 사용하지 마세요. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 전체 테이블 스캔을 수행합니다.
2) where 절의 필드에 대한 null 값 판단을 피하십시오. 그렇지 않으면 엔진이 인덱스 사용을 포기하고 다음과 같이 전체 테이블 스캔을 수행합니다.
select id from t where num is null
기본적으로 num 값은 0이고, 테이블의 num 열에 null 값이 없는지 확인한 다음 다음과 같이 쿼리합니다.
select id from t where num=0
3) 많은 경우 in is 대신 presents를 사용합니다. 좋은 선택
4) HAVING 하위를 대체하려면 Where 절을 사용하세요. 왜냐하면 HAVING은 모든 레코드를 검색한 후에만 결과 집합을 필터링하기 때문입니다
위의 인덱스를 참조하세요
1) 패러다임 최적화: 예를 들어 중복 제거(공간 절약...) 2) 안티 패러다임 최적화: 예를 들어 적절한 중복 추가(조인 감소) 3) 테이블 분할: 데이터 분할 물리적으로 서로 다른 디스크에 분리되어 서로 다른 파티션의 데이터를 서로 다른 디스크의 데이터 파일에 저장할 수 있습니다. 이런 방식으로 이 테이블을 쿼리할 때 전체 테이블을 스캔하는 대신 테이블 파티션만 스캔하면 되므로 쿼리 시간이 크게 단축됩니다. 또한 서로 다른 디스크의 파티션도 이 테이블의 데이터 전송을 서로 다른 방식으로 분산시킵니다. 신중하게 구성된 파티션인 디스크 I/O는 디스크 I/O에 대한 데이터 전송 경쟁을 균등하게 분산시킬 수 있습니다. 이 방법은 데이터 양이 많은 타임테이블에 사용할 수 있습니다. 테이블 파티션은 월 단위로 자동 생성될 수 있습니다.
4) 분할은 실제로 수직 분할과 수평 분할로 구분됩니다. 사례: 간단한 쇼핑 시스템에는 일시적으로 다음 테이블이 포함됩니다. 1. 상품 테이블(데이터 양 100,000, 안정적) 2. 주문 테이블(데이터 양 200만, 증가하는 추세) ) 3. 사용자 테이블(데이터 양: 100만 개, 증가 추세) mysql이 허용할 수 있는 규모의 범위는 수백만에서 수천만 개의 정적 데이터까지 수평 분할과 수직 분할을 설명하기 위해 mysql을 예로 들어 보겠습니다. 수직 분할: 문제 해결: 테이블 간 IO 경쟁으로는 문제가 해결되지 않습니다. 단일 테이블의 데이터 양 증가로 인한 압박 해결 방법: 제품 테이블과 사용자 테이블을 하나의 서버에 배치합니다. 수평 분할: 문제 해결: 단일 테이블의 데이터 양 증가로 인한 압력으로 문제가 해결되지 않음: 테이블 간 경쟁 해결: 사용자 테이블이 남성으로 분할됩니다. 성별에 따른 사용자 테이블과 여성 사용자 테이블 완료 및 완료 주문 테이블은 서버에 배치됩니다. 서버에 여성 사용자 테이블이 배치되어 있습니다. (여성들은 쇼핑을 좋아합니다 ㅎㅎ)
둘 사이의 유일한 차이점은 EXECUTE 문으로 트리거를 호출할 수 없다는 것입니다. 사용자가 트랜잭션을 실행합니다. SQL 문 실행을 자동으로 트리거(활성화)합니다. 트리거는 지정된 테이블의 데이터가 수정될 때 실행되는 저장 프로시저입니다. 일반적으로 트리거는 서로 다른 테이블에서 논리적으로 관련된 데이터의 참조 무결성과 일관성을 강화하기 위해 생성됩니다. 사용자는 트리거를 우회할 수 없으므로 복잡한 비즈니스 규칙을 시행하여 데이터 무결성을 보장하는 데 사용할 수 있습니다. 트리거는 저장 프로시저와 다릅니다. 트리거는 주로 이벤트 실행 트리거를 통해 실행되지만, 저장 프로시저는 저장 프로시저 이름을 통해 직접 호출할 수 있습니다. 특정 테이블에 대해 UPDATE, INSERT, DELETE 등의 작업이 수행되면 SQLSERVER는 트리거에 의해 정의된 SQL 문을 자동으로 실행하므로 데이터 처리가 이러한 SQL 문에 정의된 규칙을 준수해야 합니다. 관련 기사:
위 내용은 모으다! 인터뷰, 일반적인 MySQL 인터뷰 질문에 사용됩니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
