기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

목차

인덱스 적용

MySQL에는 어떤 인덱스가 있습니까?

일반 인덱스와 고유 인덱스의 차이점은 무엇인가요?

클러스터형 인덱스의 기본 키 인덱스를 설정하는 방법 질문: 설정하지 않으면 어떻게 되나요?

인덱스를 구축하기 위해 일반적으로 어떤 종류의 필드를 선택합니까?

인덱스가 많을수록 좋나요?

인덱스 최적화 방법 (인덱스 최적화, 인덱스 실패 방지, 기본 키 증가, 프리픽스 인덱스 최적화)

인덱스가 생성되면 쿼리 시 사용되나요? (인덱스 실패, 옵티마이저는 비용을 기준으로 실행 계획을 선택합니다.)

varchar 유형의 날짜 필드를 정의하고 데이터 중 하나가 '20230922'이고 이 날짜 필드에 인덱스가 있는 경우 쿼리의 where 조건이 작은따옴표 없이 time=20230922인 경우 왜?

최신 버전의 MySQL은 인덱스 실패 사례를 해결했습니까? (함수 인덱스: 함수에 의해 계산된 값도 인덱스할 수 있음, 인덱스 점프 스캔 메커니즘(가장 왼쪽 접두사))

가장 왼쪽의 일치 원리는 무엇입니까?

조인트 인덱스 설정 시 주의할 점은 무엇인가요? (가장 차별화된 것을 가장 왼쪽에 배치하는 것이 가장 왼쪽 매칭 원칙이며, 범위 쿼리 이후에는 인덱스를 사용하지 않음)

가장 왼쪽 일치 원칙 쿼리 순서

인덱스 푸시다운이란 무엇입니까? 데이터 쿼리 최적화를 위해 MySQL5.6에 추가됨

a>1이고 b=2이고 c <3인 인덱스를 만드는 방법은 무엇입니까?

(A,B,C) 공동 인덱스 선택 * tbn에서 a=? 및 b가 (?,?) 및 c>에 포함됩니까?

d로 정렬하여 a>100, b=100, c=123인 결합 인덱스를 만드는 방법은 무엇입니까?

age > 10이고 이름이 'xx%'인 XX에서 ID, 이름을 선택하면 공동 인덱스(이름, 나이)가 있습니다. 쿼리 프로세스에 대해 이야기해 보겠습니다.

---

인덱스 적용

MySQL어떤 지수가 있나요?

나는 MySQL이기본 키인덱스, 유니크 인덱스, 일반 인덱스, 프리픽스 인덱스,노동조합 지수이러한 유형의 인덱스.

Innodb 엔진에서는 모든 데이터베이스 테이블에기본 키색인，인덱스 열 값은 허용되지 않습니다널값。예를 들어 테이블의 id 필드는 기본 키 인덱스입니다.

고유 인덱스: 데이터 열에 있는 각 데이터 행의 고유성을 보장하되 Null 값을 허용합니다.

그 다음에자주 쿼리되는 필드의 경우 이 필드에 대한 일반 인덱스를 생성할 수 있습니다.，필드가 여러 개인 경우 생성을 고려할 수 있습니다.노동조합 지수,사용지수 적용 범위기능은 쿼리 효율성을 향상시킵니다.

긴 텍스트, 문자열 및 기사 제목, 제품 이름 등과 같은 기타 유형의 필드의 경우 이러한 필드의 접두사 부분만 색인화할 수 있습니다.인덱스의 저장 공간을 줄이기 위해 접두사 인덱스를 생성합니다.

일반 인덱스와 고유 인덱스의 차이점은 무엇입니까? 어느 쪽이 업데이트 성능이 더 좋나요? 、

• 고유 인덱스는 첫 번째 일치 항목을 찾은 후 검색을 종료할 수 있으므로 단일 값을 쿼리할 때 약간 더 빠를 수 있습니다.

• 삽입 및 업데이트 작업의 경우 일반 인덱스는 고유성 검사가 필요하지 않으므로 약간 더 빠를 수 있습니다.

1. 일반 인덱스 열의 값은 반복 가능하지만 고유 인덱스 열의 값은 고유해야 합니다. 고유 인덱스에 반복된 값을 삽입하면 고유성 제약 조건으로 인해 오류가 보고됩니다.

2. 제 생각에는일반 인덱스를 업데이트할 때 업데이트된 데이터 페이지가 그렇지 않으면 일반 인덱스의 업데이트 성능이 더 좋아집니다.메모리 그렇다면 업데이트 작업을 변경 버퍼에 직접 캐시하면 업데이트 작업이 완료됩니다. (고유성 확인이 필요하지 않음)

3. 하지만,업데이트된 데이터 페이지가 없는 경우 고유 인덱스에 고유 제약 조건이 있어야 합니다.메모리그렇다면 충돌이 있는지 확인하기 위해 디스크에서 메모리로 해당 데이터 페이지를 읽어야 합니다. 여기에는 디스크 무작위화가 포함됩니다.아이오입장.

4. 일반 인덱스는 버퍼 변경 기능을 사용할 수 있으므로 일반 인덱스의 업데이트는 고유 인덱스보다 빠릅니다.임의 디스크 액세스가 줄어들어 업데이트 성능이 향상됩니다.

클러스터형 인덱스~의기본 키질문: 인덱스를 설정하지 않으면 어떻게 되나요?

InnoDB가 클러스터형 인덱스를 생성할 때 다양한 시나리오에 따라 다양한 열을 인덱스로 선택합니다.

1. 기본 키가 있는 경우 기본 키는 기본적으로 클러스터형 인덱스의 인덱스 키로 사용됩니다.

2. 기본 키가 없으면 선택첫 번째는 포함되지 않습니다 NULL 값의 유일한 열은 다음과 같습니다.클러스터형 인덱스인덱스 키

3. 위의 사항 중 하나라도 없으면 InnoDB는 클러스터형 인덱스의 인덱스 키로 암시적 자동 증가 rowid 열을 자동으로 생성합니다.

인덱스를 구축하기 위해 일반적으로 어떤 종류의 필드를 선택합니까?

인덱싱을 적용할 수 있는 시나리오:

1. 필드에는 고유성 제한이 있습니다., 제품 코드 등

2. WHERE 쿼리 조건에서 자주 사용되는 필드이는 테이블 전체의 쿼리 속도를 향상시킬 수 있습니다. 쿼리 조건이 필드가 아닌 경우 조인트 인덱스를 설정할 수 있습니다.

3. GROUPBY 및 ORDER BY에서 자주 사용되는 필드, B+ Tree의 레코드는 모두 인덱스가 구축된 후에 정렬되므로 검색 시 다시 정렬할 필요가 없습니다.

인덱싱에 적합하지 않은 시나리오

1. WHERE 조건, GROUP BY, ORDER BY에 사용되지 않는 필드, 인덱스 값은 빠른 위치 지정입니다. 필드 위치를 지정할 수 없는 경우 인덱스가 물리적 공간을 차지하므로 일반적으로 인덱스를 만들 필요가 없습니다.

2. 구별하기 어려운 필드 , 예를 들어 성별 필드에 남성과 여성만 있으면 인덱스를 만들 필요가 없습니다. 남성과 여성의 기록이 데이터베이스 테이블에 고르게 분포되어 있으면 어떤 값을 검색하더라도 데이터의 절반이 될 수 있습니다. 얻을 수 있습니다.이런 경우에는 색인을 생성하지 않는 것이 좋습니다. MySQL아직 하나 있어요쿼리 최적화 프로그램, 쿼리 최적화 프로그램이 테이블의 데이터 행 중 높은 비율에 특정 값이 나타나는 것을 발견하면 일반적으로 인덱스를 무시하고 수행합니다.전체 테이블 스캔。

3. 자주 업데이트되는 필드예를 들어, 인덱스 필드는 자주 수정되므로 전자상거래 프로젝트의 사용자 잔액을 인덱스하지 않습니다.유지하다 비+트리질서정연한 경우 자주 인덱스를 다시 작성해야 하며 이 프로세스는 데이터베이스 성능에 영향을 미칩니다.

4. 순서가 지정되지 않은 값을 사용하는 것은 권장되지 않습니다.(ID 카드, UUID 등)을 인덱스로 사용하면 기본 키가 확실하지 않은 경우 리프 노드가 자주 분할되고 디스크 스토리지가 조각화됩니다.

• 데이터 테이블이 더 작습니다. 테이블의 데이터 양이 적거나 쿼리가 테이블의 많은 부분을 스캔해야 하는 경우 데이터베이스 최적화 프로그램은 인덱스를 사용하는 대신 전체 테이블 스캔을 선택할 수 있습니다. 이 경우 인덱스를 유지하는 데 드는 비용이 성능 향상보다 클 수 있습니다.

인덱스가 많을수록 좋나요?

아니요, 인덱스가 쿼리 효율성을 향상시킬 수는 있지만 인덱스를 하나 더 생성하면 새로운 B+ 트리 인덱스가 생성되어 저장 공간을 차지하게 되며, 특히 테이블 데이터의 양이 매우 클 경우 인덱스가 더 많은 공간을 차지하게 됩니다.

인덱스가 많을수록 테이블을 추가, 삭제, 수정할 때마다 각 B+ 트리 인덱스의 질서를 유지해야 하므로 데이터베이스의 쓰기 성능이 저하됩니다.

인덱스를 최적화하는 방법은 무엇입니까?커버링 인덱스인덱스 오류 최적화 및 방지,기본 키증분, 접두사 인덱스 최적화)

나는 이러한 최적화 방법을 사용했습니다

1. 여러 필드의 데이터를 쿼리해야 하는 SQL의 경우 다음을 만들 수 있습니다.노동조합 지수이므로 쿼리 방법은 다음과 같습니다.커버링 인덱스, 테이블 백업을 방지하고 많은 수의 I/O 작업을 줄입니다.

2. 우리의기본 키인덱스는 값이 증가하는 것이 바람직합니다., 우리 인덱스는 데이터를 순서대로 저장하기 때문에 기본 키의 값이 임의의 값인 경우 페이지 분할이 발생할 수 있습니다. 페이지 분할로 인해 많은 수의 메모리 조각이 발생하여 인덱스 구조가 간결해지지 않습니다. 쿼리 효율성에 영향을 미칩니다.

3. 우리는 원한다인덱스 실패 쓰기 방지 SQL 인덱스 열에 대해 왼쪽 또는 왼쪽 퍼지 일치를 수행하지 않는 등의 명령문은 인덱스에 대한 계산, 함수, 유형 변환 작업을 수행하지 않으며, 조인트 인덱스의 올바른 사용은 가장 왼쪽 일치 원칙을 따라야 합니다.WHERE 절에서 OR 앞의 조건 컬럼이 인덱스 컬럼이고 OR 뒤의 조건 컬럼이 인덱스 컬럼이 아닌 경우 인덱스는 실패합니다.

• 같지 않음(<>) 또는 NOT 연산자: 이 연산자는 전체 테이블을 스캔하기 때문에 일반적으로 인덱스를 무효화합니다.

• OR 연산자: 쿼리 조건에 OR가 사용되고 OR 양쪽의 조건이 서로 다른 인덱스를 포함하는 경우 해당 인덱스는 사용되지 않을 수 있습니다.

  • 사용 OR 연산자, 경우OR 양쪽의 조건에는 서로 다른 인덱스가 포함되며 데이터베이스 엔진은 대부분의 경우 쿼리를 최적화하기 위해 동시에 여러 인덱스를 사용할 수 없습니다.이것은왜냐하면 OR 연산자는 양쪽의 조건만 충족하면 되므로 쿼리 최적화가 더 복잡해집니다.

1. 일부 큰 문자열에 대한 색인, 우리는 사용을 고려할 수 있습니다접두사 색인인덱스 컬럼의 접두사 부분만 인덱스하여 인덱스 저장 공간을 절약하고 쿼리 성능을 향상시킵니다.

2. 인덱스는 NOT으로 설정하는 것이 가장 좋습니다. 없는 : 인덱스를 보다 잘 활용하기 위해서는 인덱스 컬럼을 NOT NULL 제약조건으로 설정해야 합니다. 두 가지 이유가 있습니다:

   1. 인덱스 열에 NULL이 있으면 최적화 프로그램의 인덱스 선택이 더 복잡해지고 개수와 같은 작업을 최적화하기가 더 어려워집니다.

   2. NULL 값은 의미가 없는 값이지만 물리적인 공간을 차지하게 됩니다.NULL을 저장하는 데 최소 1바이트의 공간이 사용됩니다. 값 목록

인덱스가 생성되면 쿼리 시 사용되나요?(인덱스 실패,옵티마이저비용에 따른 실행계획 선택)

아니요.

1. 나는 배웠다쿼리에서 인덱스를 사용하더라도 인덱스를 사용하지 않을 수 있습니다.

   1. 예를 들어, 쿼리 문이 인덱스 필드에 대해 왼쪽 퍼지 일치, 표현식 계산, 함수 및 암시적 유형 변환 작업을 수행하는 경우 쿼리 문은 인덱스를 통과할 수 없으며 쿼리 방법은 전체 테이블 스캔이 됩니다.

   2. 그리고 우리는노동조합 지수쿼리 시 가장 왼쪽의 일치 원칙을 따르지 않으면 인덱스 실패도 발생합니다.。

2. 최적화 프로그램은비용 고려 사항에 따라 쿼리 방법 선택, 쿼리에 보조 인덱스를 사용할 때 최적화 프로그램은 테이블 반환 비용과 전체 테이블 스캔 비용을 계산합니다. 테이블 반환 비용이 너무 높으면 최적화 프로그램은 인덱스를 사용하지 않고 인덱스를 사용하도록 선택합니다. 전체 테이블 스캔.

varchar 유형의 날짜 필드를 정의하고 데이터 중 하나가 '20230922'이고 이 날짜 필드에 인덱스가 있는 경우 쿼리의 where 조건이 작은따옴표 없이 time=20230922인 경우 왜?

인덱스에 도달하지 않습니다.

mysql이 발생하기 때문에문자열과 숫자 비교언제 일어날 것인가암시적 유형 변환, 할 것이다문자열 객체를 숫자로 변환, 이 변환 프로세스에는 실제로 다음이 포함됩니다.기능 . 언급하신 쿼리에서 날짜 필드는 문자열이므로 암시적 유형 변환이 발생하면 날짜 인덱스 필드에 적용됩니다. 인덱스에 대해 함수 계산을 수행하면 인덱스가 무효화됩니다.

예를 들어 정수 유형의 인덱스 열의 경우id 함수 계산이 발생하지 않고 인덱스에 값이 직접 저장되는 열입니다.이는 쿼리에서 사용하는 것을 의미합니다.id매칭할 때 꼭 필요한 것은 아닙니다.id함수 계산이나 변환을 수행하고 정수 값을 간단히 비교하세요.

MySQL최신 버전에서는 인덱스 실패 사례가 해결되었습니까?(함수 인덱스:함수 계산이후의 값도 인덱싱될 수 있으며 인덱스 건너뛰기 스캔 메커니즘(가장 왼쪽 접두사))

MySQL8.0이 필드를 추가할 수 있다는 것을 배웠습니다.함수 인덱스, 이 새로운 기능은 인덱스에서 함수를 사용할 때 발생하는 인덱스 오류 문제를 해결할 수 있습니다.

또 다른 새로운 기능은인덱스 스킵 스캔, 5.7 버전 이전에는 조인트 인덱스를 사용할 때 가장 왼쪽 매칭 원칙을 만족하지 않으면 인덱스 실패가 발생했지만, 8.0에서 인덱스 스킵 스캔 기능이 도입된 이후에는 가장 왼쪽 매칭 원칙을 적용하더라도 여전히 조인트 인덱스를 사용할 수 있다. 따르지 않습니다.

가장 왼쪽의 일치 원리는 무엇입니까?

(a, b, c) 조인트 인덱스가 있다고 가정하면, 저장 순서는 먼저 a로 정렬하고, a가 같을 때 b로 정렬하고, b가 같을 때 c로 정렬하는 것입니다. 이 기능으로 인해 조인트 인덱스를 사용할 때 가장 왼쪽 일치 원칙이 있습니다.

1. MySQL의 통합 인덱스는 다음에서 시작됩니다.가장 왼쪽의 인덱스 열이 쿼리 조건과 일치하기 시작하여 왼쪽에서 오른쪽으로 순서대로 일치합니다. 쿼리 조건이 열을 사용하지 않으면 해당 열의 오른쪽에 있는 모든 열을 인덱싱할 수 없습니다.

2. 쿼리 조건에 컬럼을 사용하는 경우그러나 이 열의 값에는 범위 쿼리가 포함되어 있으며 범위 쿼리의 필드를 사용할 수 있습니다.노동조합 지수, 그러나 범위 쿼리 필드 뒤의 필드에는 결합 인덱스를 사용할 수 없습니다.

따라서 조인트 인덱스를 사용할 때 가장 왼쪽 일치 원칙을 준수해야 합니다. 그렇지 않으면 일부 인덱스 필드가 인덱스되지 않을 수 있습니다.

설립하다노동조합 지수주의해야 할 점이 있나요? (가장 차별화된 것이 맨 왼쪽, 즉 가장 왼쪽에 배치되며, 범위 쿼리 후에는 인덱스가 사용되지 않습니다.)

1. 최대더 구별되는 필드를 넣습니다.노동조합 지수맨 왼쪽, 도움이 되는인덱스 필터링 효과 향상, UUID와 같은 필드는 공동 색인 열의 상단에 색인을 생성하거나 순위를 매기는 데 더 적합합니다.

2. 식별력이 낮은 필드가 조인트 인덱스의 가장 왼쪽에 배치되면 쿼리 최적화 프로그램은 인덱스를 사용하는 대신 전체 테이블을 스캔하도록 선택할 수 있습니다.

3. 조인트 인덱스의 가장 왼쪽 매칭 원리는 다음과 같습니다.범위 쿼리(예: >, <)가 발생하면 일치가 중지됩니다.즉, 범위 쿼리의 필드는 결합 인덱스를 사용할 수 있지만 범위 쿼리 필드 뒤의 필드는 결합 인덱스를 사용할 수 없습니다.그러나 >=, <=, BETWEEN 및 유사한 접두사 일치의 네 가지 범위 쿼리의 경우 일치가 중단되지 않습니다.

   1. MySQL에서 BETWEEN에는 >= 및 =<와 유사한 value1 및 value2 경계 값이 포함됩니다.

   2. 참고링크 https://zhuanlan.zhihu.com/p/573138586

가장 왼쪽 일치 원칙 쿼리 순서

select * from T where c=1 and a=2 and b=3;

abc는 인덱싱될 수 있습니다. 쿼리 조건 필드가 영향을 미치지 않는 순서, MySQL 최적화 프로그램은 필드의 쿼리 순서를 조정하는 데 도움이 되므로 가장 왼쪽 일치 원칙도 준수합니다.

인덱스 아래푸시 그것은 무엇입니까? 데이터 쿼리 최적화를 위해 MySQL5.6에 추가됨

인덱스 푸시다운을 줄일 수 있습니다.보조 인덱스쿼리 중 테이블 반환 작업은 쿼리 효율성을 향상시킵니다. 서버 계층은 스토리지 엔진 계층에서 처리하는 일부 작업을 담당합니다.그것을 처리하러 갔다.

• 인덱스 조건을 사용하지 않고 푸시다운 최적화를 수행하는 경우 스토리지 엔진은 인덱스를 통해 데이터를 검색한 후 MySQL Server로 반환합니다.MySQL 서버 필터 조건을 판단합니다.

• 인덱스 조건 푸시다운 최적화를 사용할 때 인덱스된 열에 대한 특정 판단 조건이 있는 경우 MySQL 서버는 판단 조건 중 이 부분을 스토리지 엔진으로 푸시한 다음 스토리지 엔진은 인덱스가 전달된 조건을 충족하는지 여부를 판단합니다. MySQL 서버. 인덱스가 조건을 충족하는 경우에만 데이터가 검색되어 MySQL 서버로 반환됩니다.

인덱스 조건 푸시다운 최적화는 스토리지 엔진이 기본 테이블을 쿼리하는 횟수를 줄일 수 있으며, 또한 MySQL 서버가 스토리지 엔진으로부터 데이터를 수신한 횟수입니다.

select * from t_user where age > 20 and reward = 100000;

a>1이고 b=2이고 c <3인 인덱스를 만드는 방법은 무엇입니까?

1. (abc), (acb), (ab), (ac) 조인트 인덱스 생성, 캔 인덱스만 가능

2. (cab), (cba), (ca), (cb) 조인트 인덱스 생성, c만 인덱스 가능

3. (ba) 조인트 인덱스 생성, b와 a 모두 인덱스 가능

4. (bc) 조인트 인덱스 생성, b와 c 모두 인덱스 가능

5. 생성(백) 노동조합 지수, b 및 a는 모두 인덱싱할 수 있지만 (보다 느립니다.바) 조인트 인덱스에는 또 다른 이점이 있습니다. c 필드는 다음과 같습니다.인덱스 푸시다운, 테이블 반환 횟수가 줄어 듭니다.

6. 만들다(비씨에이) 노동조합 지수, b와 c는 모두 인덱싱될 수 있지만 (bc) 결합 인덱스보다 한 가지 더 많은 장점이 있습니다.인덱스 푸시다운, 테이블 반환 횟수가 줄어 듭니다.

(A,B,C) 관절 지수 select * from tbn where a=? and b in (?,?) and c>? 색인이 생성되나요?

이 쿼리는 공동 인덱스를 사용합니다 (A,B,C), 조건이 인덱스 열을 기반으로 하기 때문입니다. A、B、C 주문이 들어오면 이는 이상적인 사용 시나리오입니다.

1. ~을 위한 A=?: 이 조건은 정확히 일치합니다. MySQL은 인덱스를 사용하여 조건을 만족하는 조건을 찾습니다. A=? 의 기록.

2. ~을 위한 B IN (?, ?): 이 조건은 다음을 지정합니다. B 열은 두 가지 가능한 값을 가질 수 있습니다. MySQL은 인덱스를 사용하여 모든 일치 항목을 찾습니다.A=? 그리고B 열은 이 두 값 중 하나를 포함하는 레코드입니다.

3. ~을 위한 C>? : 이 조건은 범위 쿼리입니다.이미 기반으로A 그리고B 필터를 기반으로 MySQL은 계속해서 인덱스를 사용하여 다음을 찾습니다.C 지정된 값보다 큰 열 값으로 기록합니다.

여기서 a>100이고 b=100이고 c=123입니다. d로 정렬하는 방법노동조합 지수?

제 생각에는설립하다 비씨다 순서대로노동조합 지수더 나은, 현재 b 및 c 필드 모두 색인화될 수 있으며,d는 파일 정렬(추가 정렬)을 피하기 위해 인덱스 순서를 사용할 수 있습니다., 마지막 a 필드는 인덱싱할 수 없지만(a 순서가 잘못됨) 인덱스를 사용하여 푸시다운하여 테이블 반환 수를 줄일 수 있습니다.

select id ,name from XX where age > 10 and name like'xx%'，有노동조합 지수(이름, 나이), 쿼리 프로세스에 대해 이야기해 보세요.

결합 인덱스의 순서는 이름이 먼저이고 나이가 순서입니다. 구조적으로 이름이 먼저 정렬되고 이름이 같을 경우 나이가 정렬됩니다.따라서 옵티마이저는 name을 먼저 일치시켜야 합니다. 이때 Name은 올바른 퍼지 쿼리이므로 인덱스 실패가 발생하지 않으므로 이 SQL은 조인트 인덱싱을 사용할 수 있습니다.

구체적으로는 이름만 색인화할 수 있기 때문이다.이름 오른쪽 퍼지 쿼리 이후 age 필드의 값이 순서가 맞지 않아서 age는 index가 안 되지만 age는 index가 가능하다.인덱스 푸시다운。

마지막으로 쿼리되는 필드는 id와 name입니다. 이 두 필드는 공동 인덱스에서 찾을 수 있으므로 테이블을 반환할 필요가 없습니다.

이름 오른쪽 퍼지 쿼리는 범위 쿼리이므로 다음 필드를 인덱싱할 수 없습니다.