개요
최적화하는 이유
- 시스템 처리량 병목 현상은 종종 데이터베이스 액세스 속도에 나타납니다.
- 응용 프로그램이 실행됨에 따라 데이터베이스에 데이터가 점점 더 많아지고 그에 따라 처리 시간이 느려집니다.
- 데이터는 디스크에 저장되며 읽기 및 쓰기 속도는 메모리와 비교할 수 없습니다.
최적화하는 방법
- 데이터베이스 설계시 : 데이터베이스 테이블 및 필드 설계, 스토리지 엔진
- 인덱스와 같이 MySQL 자체에서 제공하는 기능을 잘 활용하십시오.
- 수평 확장 : MySQL 클러스터,로드 밸런싱, 읽기-쓰기 분리
- SQL 문 최적화 (효과가 거의 없음)
1 MySQL의 두 가지 일반적인 스토리지 엔진 인 MyISAM과 InnoDB에 대한 나의 이해에 대해 이야기하십시오.
두 가지 비교 및 요약 정보 :
카운트 연산의 차이 : MyISAM 캐시에는 테이블 메타 데이터 (행 수 등)가 있기 때문에 COUNT (*)를 수행 할 때 잘 구조화 된 쿼리를 위해 많은 리소스를 소비 할 필요가 없습니다. InnoDB의 경우 이러한 캐시가 없습니다.
충돌 후 트랜잭션 및 안전한 복구 지원 여부 : MyISAM은 성능을 강조하고 각 쿼리는 원자 적이며 실행이 InnoDB 유형보다 빠르지 만 트랜잭션 지원을 제공하지 않습니다. 그러나 InnoDB는 트랜잭션 지원 트랜잭션 및 외래 키와 같은 고급 데이터베이스 기능을 제공합니다. 트랜잭션 (커밋), 롤백 (롤백) 및 충돌 복구 기능 (충돌 복구 기능)이있는 트랜잭션 안전 (ACID 호환) 유형 테이블.
외래 키 지원 여부 : MyISAM은 지원하지 않지만 InnoDB는 지원합니다.
MyISAM은 읽기 집약적 인 테이블에 더 적합하고 InnoDB는 쓰기 집약적 인 테이블에 더 적합합니다. 데이터베이스 분리의 경우 MyISAM이 주 데이터베이스의 스토리지 엔진으로 종종 선택됩니다. 일반적으로 트랜잭션 지원이 필요하고 동시 읽기 빈도가 더 높은 경우 (MyISAM의 테이블 잠금 세분성이 너무 커서 테이블 쓰기 동시성이 높으면 대기해야 할 쿼리가 많음) InnoDB 좋은 선택입니다. 데이터 양이 많고 (MyISAM은 디스크 공간 사용량을 줄이기 위해 압축 기능을 지원함) 트랜잭션을 지원할 필요가없는 경우 MyISAM이 최선의 선택입니다.
2 데이터베이스 색인을 이해하고 있습니까?
내가 추가 한 콘텐츠 중 일부는 다음과 같습니다.
인덱스가 쿼리 속도를 향상시킬 수있는 이유는 무엇입니까?
MySQL의 기본 스토리지 구조부터 시작하겠습니다.
MySQL의 기본 저장 구조는 페이지입니다 (레코드는 페이지에 저장 됨).
각 데이터 페이지는 이중 연결 목록을 형성 할 수 있습니다.
각 데이터 페이지의 레코드는 단일 연결 목록을 형성 할 수 있습니다.
각 데이터 페이지는 저장된 레코드에 대한 페이지 디렉터리를 생성합니다. 기본 키를 통해 레코드를 검색 할 때 페이지 디렉터리의 이분법을 사용하여 해당 슬롯을 빠르게 찾은 다음 해당 슬롯 그룹을 순회 할 수 있습니다. 지정된 레코드를 빠르게 찾으려면
검색 기준으로 다른 열 (기본 키가 아님)을 사용합니다. 단일 연결 목록의 각 레코드는 가장 작은 레코드부터 순차적으로 만 순회 할 수 있습니다.
따라서 최적화없이 SQL 문과 같은 indexname = 'xxx'인 select * from user를 작성하면 기본적으로 다음 작업을 수행합니다.
레코드가있는 페이지 찾기 : 페이지를 찾으려면 이중 연결 목록을 탐색해야합니다.
현재있는 페이지에서 해당 레코드를 찾습니다. 기본 키 쿼리를 기반으로하지 않기 때문에 현재있는 페이지의 단일 연결 목록 만 통과 할 수 있습니다.
데이터 양이 많으면이 검색이 매우 느릴 것입니다! 이번 복잡성은 O (n)입니다.
색인 사용 후
인덱스는 쿼리 속도를 높이기 위해 무엇을 할 수 있습니까? 실제로 무질서한 데이터를 순서대로 (상대적으로) 바꿉니다.
ID가 8 인 레코드를 찾는 간단한 단계 :
당연히 : 색인을 생성하지 않고 해당 페이지를 찾기 위해 이중 연결 목록을 탐색해야합니다. 이제 "디렉토리"를 통해 해당 페이지 를 빠르게 찾을 수 있습니다! (바이너리 검색, 시간 복잡도는 대략 O (logn)) 사실 기본 구조는 B + 트리입니다. 트리 구현으로 B + 트리를 사용하면 해당 레코드를 빠르게 찾을 수 있습니다.
다음 내용은 "The Way of Java Engineer Practice"에서 구성됩니다.
맨 왼쪽 접두사 원칙
MySQL의 인덱스는 특정 순서로 여러 열을 참조 할 수 있으며 이러한 유형의 인덱스를 조인트 인덱스라고합니다. 예를 들어, User 테이블의 이름과 도시에 공동 인덱스를 더한 값은 (name, city) o이고 맨 왼쪽 접두사 원칙은 쿼리 조건이 인덱스 왼쪽의 하나 또는 여러 열과 정확히 일치하는 경우이 열을 사용할 수 있음을 나타냅니다. 에. 다음과 같이 :
select * from user where name = xx and city = xx; // can hit the index
select * from user where name = xx; // can hit the index
select * from user where city = xx; // 색인에 도달 할 수 없음
쿼리에서 두 조건이 모두 사용되지만 city = xx 및 name = xx와 같이 순서가 다른 경우 현재 쿼리 엔진이 공동 인덱스의 순서와 일치하도록 자동으로 최적화되어 히트 할 수 있습니다. 색인이 생성되었습니다.
가장 왼쪽 접두사의 원칙으로 인해 공동 인덱스를 생성 할 때 인덱스 필드의 순서는 중복 제거 후 필드 값의 수를 고려하고 더 많은 것을 맨 앞에 배치해야합니다.
ORDERBY 절도이 규칙을 따릅니다.
중복 인덱스를 피하도록주의하십시오.
중복 인덱스는 인덱스의 동일한 기능을 의미합니다. 히트 할 수 있으면 확실히 히트합니다. 그러면 중복 인덱스입니다. 두 인덱스 (이름, 도시) 및 (이름)은 중복 인덱스입니다. 후자를 히트 할 수있는 쿼리는 다음과 같아야합니다. 대부분의 경우 전자를 칠 수 있다면 새 인덱스를 만드는 대신 기존 인덱스를 확장해야합니다.
MySQLS.7 버전 이후에는 sys 라이브러리의 scheme_r dundant_indexes 테이블을 쿼리하여 중복 인덱스를 확인할 수 있습니다.
MySQL은 테이블 필드에 인덱스를 어떻게 추가합니까? ? ?
1. PRIMARY KEY (기본 키 인덱스) 추가
ALTER TABLE`table_name` ADD PRIMARY KEY (`column`)
2. UNIQUE (고유 색인) 추가
ALTER TABLE`table_name` ADD UNIQUE (`column`)
3. INDEX (일반 인덱스) 추가
ALTER TABLE`table_name` ADD INDEX index_name (`column`)
4. FULLTEXT (전체 텍스트 인덱스) 추가
ALTER TABLE`table_name` ADD FULLTEXT (`column`)
5. 다중 열 색인 추가
ALTER TABLE`table_name` ADD INDEX index_name (`column1`,`column2`,`column3`)
3 큰 테이블에 대한 일반적인 최적화 방법에 대해 이야기
4 단일 MySQL 테이블의 레코드 수가 너무 많으면 데이터베이스의 CRUD 성능이 크게 저하되며 일반적인 최적화 방법은 다음과 같습니다.
단일 MySQL 테이블의 레코드 수가 너무 많으면 데이터베이스의 CRUD 성능이 크게 저하됩니다. 몇 가지 일반적인 최적화 조치는 다음과 같습니다.
데이터의 범위를 제한 1 : 데이터 범위를 제한하는 어떠한 조건없이 쿼리 문을 금지해야합니다. 예를 들어 사용자가 주문 내역을 쿼리 할 때 한 달 이내에 제어 할 수 있습니다. ；
2. 읽기 / 쓰기 분리 : 고전적인 데이터베이스 분할 체계, 메인 라이브러리가 쓰기를 담당하고 슬레이브 라이브러리가 읽기를 담당합니다.
3. 수직 분할 : 데이터베이스 내 데이터 테이블의 상관 관계에 따라 분할합니다. 예를 들어 사용자 테이블에 사용자의 로그인 정보와 사용자의 기본 정보가 모두 포함되어있는 경우 사용자 테이블을 두 개의 개별 테이블로 분할하거나 하위 데이터베이스 용으로 별도의 데이터베이스에 넣을 수도 있습니다. 간단히 말해, 수직 분할은 데이터 테이블 열을 분할하여 많은 열이있는 테이블을 여러 테이블로 분할하는 것을 말합니다. 아래 그림과 같이 누구나 이해하기 쉬워야합니다.
수직 분할의 장점 : 행 데이터를 더 작게 만들고 쿼리 중에 읽는 블록 수를 줄이고 I / O 수를 줄일 수 있습니다. 또한 수직 분할은 테이블 구조를 단순화 할 수 있으며 유지 보수가 쉽습니다.
수직 분할의 단점 : 기본 키가 중복되고 중복 된 열을 관리해야하며 조인 작업이 발생하며 이는 애플리케이션 계층에서 조인하여 해결할 수 있습니다. 또한 수직 분할은 트랜잭션을 더 복잡하게 만듭니다.
4. 수평 분할 : 데이터 테이블 구조를 그대로 유지하고 특정 전략을 통해 데이터 조각을 저장합니다. 이러한 방식으로 각 데이터 조각이 서로 다른 테이블 또는 라이브러리에 분산되어 배포 목적을 달성합니다. 수평 분할은 매우 많은 양의 데이터를 지원할 수 있습니다. 수평 분할은 데이터 테이블 행을 분할하는 것을 의미합니다. 테이블 행 수가 200 만 행을 초과하면 속도가 느려집니다. 이때 한 테이블의 데이터를 여러 테이블로 분할하여 저장할 수 있습니다.
예를 들어, 사용자 정보 테이블을 여러 사용자 정보 테이블로 분할하여 너무 큰 단일 테이블의 성능 영향을 피할 수 있습니다.
수평 분할은 매우 많은 양의 데이터를 지원할 수 있습니다. 한 가지 유의해야 할 점은 분할 테이블은 단일 테이블의 너무 큰 데이터 문제 만 해결하지만 테이블의 데이터가 여전히 동일한 시스템에 있기 때문에 MySQL의 동시성을 향상시키는 것은 의미가 없으므로 수평 분할이 데이터베이스를 분할하는 것이 가장 좋습니다. . 수평 분할은 매우 많은 양의 데이터 스토리지를 지원할 수 있으며 애플리케이션 측 변환은 거의 없지만 단편화 트랜잭션은 해결하기 어렵고 국경 간 조인 성능이 나쁘고 논리가 복잡합니다.
"The Practice of Java Engineers"의 저자는 가능한 한 데이터를 분할하지 말 것을 권장합니다. 분할은 논리, 배포, 운영 및 유지 관리의 다양한 복잡성을 가져오고 일반 데이터 테이블은 적절한 최적화 조건에서 1,000 만 개 미만을 지원할 수 있기 때문입니다. 데이터의 양은 큰 문제가 아닙니다. 정말 조각화하고 싶다면 네트워크 I / O와 미들웨어를 한 번 줄일 수있는 클라이언트 조각화 아키텍처를 선택하십시오.
다음은 데이터베이스 조각화에 대한 두 가지 일반적인 시나리오입니다.
클라이언트 프록시 : 단편화 로직은 애플리케이션 측에 있으며 jar 패키지에 캡슐화되고 JDBC 레이어를 수정하거나 캡슐화하여 구현됩니다 . Dangdang의 Sharding-JDBC 와 Ali의 TDDL은 일반적으로 사용되는 두 가지 구현입니다.
미들웨어 에이전트 : 애플리케이션과 데이터 사이에 에이전트 계층이 추가됩니다. 샤딩 로직은 미들웨어 서비스에서 균일하게 유지됩니다. 우리는 이제 Mycat 에 대해 이야기하고 있습니다 . 360의 Atlas, Netease의 DDB 등은 모두이 아키텍처의 구현입니다.
끝에 쓰기
공간상의 이유로 위의 내용 중 일부만 pdf 파일로 편집하여 도움이 필요한 사람들에게 무료로 공유합니다.
여기에있는 모든 사람들을위한 "Golden Nine and Silver Ten"구직 시즌에 대한 Java 설계자 학습 비디오와 Java 백엔드 인터뷰 정보를 편집했습니다.
자바 아키텍트 학습 자료 :
- 필기 Mybatis
- 알리 인터뷰에서 요구하는 JVM을 어떻게 배워야합니까?
- 동시 프로그래밍 필기 JDK 잠금의 기본 원칙
- Spring 트랜잭션 소스 코드 분석
- 초당 높은 동시성 성능 스턴트
- 그리고 더 많은
자바 인터뷰 질문 :
- Linux 인터뷰 주제 및 답변
- JVM 인터뷰 주제 및 답변
- 자바 기본 인터뷰 질문
- Kafka 인터뷰 주제 및 답변
- Dubbo 인터뷰 및 답변
- Netty 인터뷰 주제 및 답변
- ActiveMQ 메시지 미들웨어 인터뷰 주제
- 메시지 미들웨어 인터뷰 주제 및 답변
- 데이터베이스 인터뷰 주제 및 답변
- 마이크로 서비스 인터뷰 주제 및 답변
- 인터뷰를위한 낙관적이고 비관적 인 자물쇠
- 오픈 소스 프레임 워크 인터뷰 주제 및 답변
- 디자인 패턴 인터뷰 주제 및 답변
- 다중 스레드 인터뷰 주제 및 답변
- 사육사 인터뷰 주제 및 답변
- 동시 프로그래밍 인터뷰 주제 및 답변
- 그리고 더 많은
이 기사에 요약 된 코스 개요 (PDF 버전)가 필요한 친구, Java 아키텍트 학습 비디오 및 Java 인터뷰 질문이 "이타적인 공유"의 정신으로
