>  기사  >  데이터 베이스  >  MySQL 연구 노트(4)는 데이터베이스 인덱스에 대해 이야기합니다.

MySQL 연구 노트(4)는 데이터베이스 인덱스에 대해 이야기합니다.

黄舟
黄舟원래의
2016-12-21 16:43:50983검색

기분이 조금 (구분선으로 바로 이동 가능)

오늘 기분이 더 좋아요. 해결되지 않는 강한 나쁜 감정들은 밤에 복잡한 논리적 문제를 해결한 후에 점차 소멸되었습니다.

오늘 정오에 식사하러 갔을 때 쿤 형제가 아무렇지 않게 이렇게 말했습니다. '오랜 세월이 지나서야 비로소 진리를 깨달았습니다. 사람이 젊을 때는 다른 일을 할 시간이 없기 때문에 그렇게 열심히 일해서는 안 됩니다. things'

내가 다른 것에 대해 물었을 때 쿤 형제는 나를 쳐다보며 너무 바빠서 사랑에 빠질 시간이 없었다고 태연하게 계속 말했다.

그렇게 열심히 안 해도 괜찮을 것 같은데요? 집값은 해마다 오르고, 생활비는 나날이 오르고 있다. 자신의 가치를 만들기 위해 열심히 일하지 않으면, 당신이 버는 돈은 경제성장률을 초과합니다. 그러면 우리는 계속해서 사회의 밑바닥에서 패배자로 남을 수 밖에 없고, 좋은 청춘의 시절에도 계속 고통 속에 살아가게 될 뿐입니다.

열심히 일하는 것만으로는 충분하지 않습니다. 열심히 노력해야만 다른 사람들과의 경쟁에서 약간의 우위를 점할 수 있습니다.

그렇게 열심히 일한다는 게 너무 고통스럽고, 삶은 매우 단조롭습니다. 어떤 여자가 이런 삶을 좋아할까요?

지난 6개월 동안 저의 감성지능과 대인관계 능력이 떨어지는 것은 프로그래밍에 온 몸과 마음을 쏟았던 것과 관련이 있는 것 같습니다.

원래는 쿤 형제님과 이야기할 때 이 단어를 사용하고 싶었는데, 결국 말이 목에 걸려서 말하지 못했습니다.

외롭든 활기차든 누구에게나 자신만의 길이 있고 그것은 자신의 선택입니다.

길을 선택하면 많은 것을 버려야 합니다.

얻을 의향이 있으니 잃겠다는 마음이 더욱 강하다.

호언장담 후 텍스트가 시작됩니다.

색인이 무엇인가요? 전문 용어에 쉽게 속는 학생들은 책과 자료를 검색하는 도구인 바이두(Baidu)에 대한 대중적인 설명을 솔선적으로 읽어야 합니다. 단행본, 정기간행물의 내용이나 항목을 분류, 추출하고, 페이지 수를 표시하고, 일정한 순서로 배열하여 단행본에 첨부하거나, 독자의 편의를 위해 별도의 단행본으로 정리합니다. 이전에는 일반 검사 또는 준비 검사로 알려져 있었습니다. 납이라고도 합니다.

"MySQL 핵심 기술 및 모범 사례" 장이 훌륭해서 오늘 내용의 대부분은 책에 있는 내용을 요약한 것입니다.

색인을 더 쉽게 이해하세요. 색인은 신화사전 앞 부분에 병음과 부수로 단어를 검색하는 부분입니다.

생활에서 희귀한 단어의 발음을 모르고 획을 사용하여 검색하지 않으면 검색하기가 매우 어려울 수 있습니다. 전체 사전의 모든 단어를 검색하여 일치시킨 후 반환합니다. 이로 인해 전체 테이블 스캔이 발생하며 이는 매우 비효율적입니다.

그러나 부수와 획을 통해 찾는다면 우리가 찾을 수 있는 데이터의 양은 매우 적습니다. 기계에 맡기고 관련 데이터 항목만 스캔하면 매우 빠릅니다. .

따라서 쿼리 속도는 데이터 크기와 절대적인 관계가 없습니다. 쿼리 속도는 검색되는 테이블 데이터 수와 스캔되는 테이블 데이터 수에 따라 달라집니다. 비율이 작을수록 효율성이 높아집니다.

몇 가지 중요한 지식 포인트:

1. MySQL은 테이블의 데이터를 검색할 때 먼저 인덱스 "keyword" 값에 따라 인덱스에서 검색합니다. 발견되면 시작 페이지를 직접 찾을 수 있습니다. 그렇지 않으면 전체 테이블이 스캔됩니다.

Liu Xijun의 노래 "Forget Him"을 듣고 다음 내용을 요약하기 시작했습니다.

2. 인덱스는 실제로 데이터베이스 테이블에 있는 필드 값의 복사본이며, 변경된 필드를 인덱스의 키라고 합니다.

3. 데이터 테이블은 여러 개의 인덱스를 생성할 수 있습니다.

4. 접두사 색인이란 무엇입니까?

신화사전의 '급진 색인'을 사용하는 방법입니다. 먼저 찾고자 하는 단어의 부수가 무엇인지 먼저 확인한 후, 부수 밖의 단어의 획을 살펴본 후 해당 단어를 검색합니다. 마찬가지로 데이터베이스 테이블의 경우 인덱스의 키워드 값은 인덱스의 "키워드"의 일부일 수 있습니다. 이러한 종류의 인덱스를 "접두사 인덱스"라고 합니다. 예를 들어 이름 테이블에 대한 접두사 인덱스를 만들 수 있습니다. 사용자 테이블에서 Zhang의 성을 계산합니다.

데이터베이스의 경우 인덱스가 될 수 있나요? , 인덱스는 데이터베이스 테이블의 필드 조합일 수 있습니다. 인덱스가 여러 키워드로 구성된 경우 이를 복합 인덱스라고 합니다. 인덱스가 하나의 필드인지 여러 필드의 조합인지에 관계없이 이러한 필드는 동일한 것에서 나와야 합니다. Bianche 키워드의 값은 테이블의 해당 필드여야 합니다.

6. 인덱스는 여러 테이블에 걸쳐 생성할 수 없습니다.

7. 추가 저장 공간이요?

예를 들어 소가 잘 뛰는데 소가 풀을 먹지 않기를 바라는 경우에 이 질문은 말도 안 됩니다. 데이터베이스 테이블의 경우 인덱스 키는 정렬 후 외부 메모리에 저장됩니다. MyISAM 데이터베이스 테이블의 경우 인덱스는 MYI 인덱스 파일에 저장됩니다. InnoDB 스토리지 엔진의 경우 인덱스 데이터는 외부 InnoDB 테이블 공간 파일에 저장됩니다. (공유 테이블스페이스 파일일 수도 있고 단독 테이블스페이스 파일일 수도 있음) 테이블의 인덱스는 여전히 InnoDB 인덱스입니다.

8. 테이블의 인덱스로 선택하기에 적합한 필드는 무엇입니까? 기본 인덱스는 무엇이며 클러스터형 인덱스는 무엇입니까?

MyISAM 테이블의 경우 MySQL은 테이블에 있는 모든 레코드의 기본 키 값 백업과 각 레코드의 시작 페이지를 자동으로 인덱싱합니다. "인덱스 테이블"은 기본 검색 테이블처럼 생성되어 외부 메모리에 저장됩니다. MyISAM 테이블의 MYI 인덱스 파일과 MYD 데이터 파일은 두 개의 파일에 위치합니다. MYI 인덱스 파일의 "테이블 레코드 포인터"를 통해 MYD 데이터 파일의 테이블 레코드가 위치한 물리적 주소를 찾을 수 있습니다.

Innodb 테이블의 "기본 인덱스"는 MyISAM 테이블의 기본 인덱스와 다릅니다. InnoDB 테이블의 기본 인덱스 키 순서는 InnoDB 테이블에 기록된 기본 키 값의 순서와 일치합니다. 이러한 종류의 인덱스를 "클러스터형 인덱스"라고 하며, 각 테이블은 하나의 클러스터형 인덱스만 가질 수 있습니다.

9. 인덱스와 데이터 구조는 어떤 관계인가요?

데이터베이스의 키워드를 인덱스 파일에 저장하는 규칙은 매우 복잡합니다. 데이터베이스 검색의 효율성을 효과적으로 향상시키기 위해. 인덱스는 일반적으로 균형 트리(btree) 또는 해시 테이블과 같은 복잡한 데이터 구조를 사용하여 "구성"됩니다. 데이터베이스를 운영할 때 기본 연산이 이렇게 복잡한 연산을 수행하고 있는데 우리는 그것을 느낄 수 없습니다.

10. 인덱스가 많을수록 좋은가요?

인덱스가 너무 많은 경우 데이터 업데이트(추가, 수정, 삭제) 시 테이블의 데이터 수정 외에도 테이블의 모든 인덱스도 유지하여 테이블 필드 값을 유지해야 합니다. ​및 키워드 값 일관성을 색인화합니다. 오히려 데이터 업데이트 속도가 느려집니다.

테이블 이름 연습. 테이블 레코드 수정 작업이 특히 자주 발생하는 경우 인덱스가 너무 많으면 하드 디스크 I/O 수가 크게 증가하여 서버 성능이 크게 저하됩니다. 다운타임이 발생할 수도 있습니다.

11. 인덱스 키워드 선정 원칙.

원칙 1. 테이블 내 필드의 분산도가 높을수록 해당 필드가 인덱싱 대상으로 선택된 키워드로 적합합니다.

데이터베이스 사용자가 기본 키 제약 조건을 생성하면 MySQL은 자동으로 기본 인덱스(기본 인덱스)를 생성하고 고유 제약 조건을 생성할 때 인덱스 이름은 기본입니다. MySQL은 자동으로 고유 제약 조건(고유 인덱스)을 생성합니다. ) 기본적으로 인덱스 이름은 고유 바인딩 제약 조건의 필드 이름입니다.

원칙 2. 저장 공간을 적게 차지하는 필드가 색인용 키워드로 선택되기에 더 적합합니다.

원칙 3. 저장 공간이 고정된 필드가 색인 키워드로 선택되기에 더 적합합니다.

원칙 4: where 절에서 자주 사용되는 필드에 대해 인덱스를 생성하고, 필드 그룹화 또는 필드 정렬을 위해 인덱스를 생성하며, 두 테이블 간의 연결 필드에 대해 인덱스를 생성해야 합니다.

어젯밤에는 잠이 오지 않았습니다. 공간을 탐색하던 중 친구가 이혼했다는 소식을 듣게 되었습니다. 그 사람은 내가 대학시절 좋아했던 여자였는데, 그 사람의 고집 등의 이유로 잠시 동거했다가 헤어졌어. 저는 결혼한 지 1년밖에 안 됐고 아이도 있어요. 문득 가슴이 아프고, 과거로 돌아가는 상상을 하게 됩니다. 별이 하늘을 가득 채웠던 그날 밤, 나는 고집스럽고 고집스러웠고 그녀는 따뜻하고 향기로웠습니다. 잊어 버리세요. 이런 일에 대해 슬퍼하지 않는 것이 좋습니다. 모든 사람은 죽을 운명입니다. 제대로 코딩하는 것이 좋습니다.

index를 도입한 목적은 검색의 효율성을 높이는 것이기 때문에 index 키워드의 선택은 select 문과 밀접한 관련이 있습니다. 이 문장에는 두 가지 의미가 있습니다. select 문의 디자인은 인덱스의 디자인에도 영향을 미칩니다. select 문의 where 절, group by 절, order by 절도 인덱스 디자인에 영향을 줄 수 있습니다. 두 테이블의 링크 필드에 대해 인덱스를 생성해야 합니다. 외래 키 제약 조건이 생성되면 MySQL은 외래 키 필드가 일반적으로 두 테이블의 연결 필드이기 때문에 자동으로 생성됩니다.

원칙 5. 자주 업데이트되는 필드는 인덱스 생성에 적합하지 않으며, where 절에 나타나지 않는 필드는 인덱스를 생성해서는 안 됩니다.

원칙 6. 가장 왼쪽 접두사의 원칙.

복합 인덱스의 또 다른 장점은 "가장 왼쪽 접두사"라는 개념에 반영됩니다. 테이블의 여러 필드(예: firstName, lastName, address)가 생성된다고 가정합니다. 복합 인덱스(인덱스) 이름: 이름_성_주소). where 쿼리의 조건이 다음 필드의 조합인 경우 mysql은 fname_lastname_address 인덱스를 사용합니다. fname_lastname_address 인덱스는 다른 경우에는 사용되지 않습니다.

이름,성,주소

이름,;성

이름

원칙 7. 접두사 색인을 사용해 보세요.

이름 중 성 부분에만 색인을 생성하면 색인의 저장 공간이 절약되고 검색 효율성이 향상됩니다.

데이터베이스 디자인과 마찬가지로 인덱스 디자인 역시 데이터베이스 개발자의 경험과 지혜의 축적이 필요한 동시에, 시스템 각각의 특성에 맞춰 더 나은 인덱스를 디자인하는 '사이'가 필요하다. 효율성'과 '업데이트 속도를 낮추는 것' 사이의 균형을 맞추세요. 이는 데이터베이스의 전반적인 성능을 크게 향상시킵니다.

색인과 제약조건 관계:

mysql에서 인덱스와 제약조건은 어떤 관계가 있나요? 제약 조건은 기본 키 제약 조건, 고유 제약 조건, 기본값 제약 조건, 검사 제약 조건, Null이 아닌 제약 조건, 외래 키 제약 조건으로 구분됩니다. 그 중에서 기본 키 제약 조건, 고유 제약 조건, 외래 키 제약 조건 및 인덱스는 더 밀접하게 관련되어 있습니다.

제약조건은 주로 비즈니스 로직으로 데이터베이스를 운영할 때 데이터베이스의 무결성을 보장하기 위해 사용됩니다.

인덱스는 외부 메모리의 키워드 데이터를 특정 데이터 구조(예: btree, 바이너리 트리, 해시 등)로 저장하여 데이터 검색 성능을 향상시킵니다.

제약 조건은 논리적 수준의 개념인 반면, 인덱스는 논리적 개념일 뿐만 아니라 물리적인 저장 방법이기도 하며, 존재한다는 점에서 일정량의 저장 공간이 필요합니다.

인덱스 이름 고유 인덱스

인덱스 이름 일반 인덱스

인덱스 complex_index(price,publish_time) 복합 인덱스

이 글의 내용 대부분을 발췌하였습니다. "MySQL 핵심 기술 및 모범 사례"에 관심이 있는 친구들은 이 책을 구입하여 읽어볼 수 있습니다. 정말 잘 쓰여졌습니다.

위 내용은 데이터베이스 인덱싱에 관한 Mysql 연구노트(4) 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!


성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.