"MySQL 성능 튜닝 학습 맵"요약

반복 된 실패 후에 저는이 백만 자의 "MySQL 성능 조정 노트"를 요약했습니다.

참고 :이 문서는 공간이 제한되어 있으므로 일부 콘텐츠 만 표시됩니다. "MySQL 성능 튜닝 학습 맵"은 수집 및 구성이 쉽지 않습니다. 도움이 필요한 친구가 도움을 줄 수 있습니다. 좋아요를 누른 다음 여기 를 클릭 하여 다운로드하십시오. 무료 방법

하나, 성능 모니터링

1. show profile 쿼리 분석 도구를 사용하여 특정 유형을 지정합니다.

이 도구는 기본적으로 비활성화되어 있으며 서버 변수를 통해 도면 수준에서 동적으로 수정할 수 있습니다.

set profiling=1;

설정이 완료되면 서버에서 실행되는 모든 문은 소요 시간 및 쿼리 실행 상태 변경과 관련된 기타 데이터를 측정합니다.

select * from emp;

mysql 명령 줄 모드에서는 소수점 이하 두 자리 만 표시 할 수 있으며 다음 명령을 사용하여 특정 실행 시간을 볼 수 있습니다.

show profiles;

다음 명령을 실행하여 각 단계의 자세한 시간을 확인합니다.

show profile for query 1;

2. 성능 스키마를 사용하여 mysql을보다 쉽게 모니터링

상세한 MYSQL 성능 스키마

performance_schema 소개
성능 스키마 시작하기
performance_schema 테이블의 분류
performance_schema의 간단한 구성 및 사용
공통 구성 항목의 매개 변수 설명
중요한 구성 테이블에 대한 설명
성능 _ 스키마 실습 운영

3. show processlist를 사용하여 연결된 스레드 수를보고 많은 수의 스레드가 비정상 상태인지 또는 기타 비정상 특성인지 관찰합니다.

id는 세션 ID를 의미합니다.
user는 작업의 사용자를 나타냅니다.
host는 작업의 호스트를 나타냅니다.
db는 운영 데이터베이스를 나타냅니다.
명령은 현재 상태를 나타냅니다.
정보는 자세한 sq1 언어 방향을 나타냅니다.
시간은 해당 명령의 실행 시간을 나타냅니다.
state는 명령 실행 상태를 나타냅니다.

둘째, 스키마 및 데이터 유형 최적화

1. 데이터 유형 최적화

일반적으로 작을수록 좋습니다. 데이터를 올바르게 저장할 수있는 가장 작은 데이터 유형을 사용하십시오. 데이터 유형이 작을수록 디스크, 메모리 및 CPU 캐시를 덜 차지하고 처리에 필요한 CPU주기가 더 적기 때문에 일반적으로 더 빠릅니다. 저장해야하는 값의 범위를 과소 평가하지 마십시오. 어떤 데이터 유형을 확인할 수없는 경우 범위를 초과하지 않을 것이라고 생각되는 가장 작은 유형을 선택하십시오.

단순함이 더 낫습니다 : 단순 데이터 유형의 연산은 일반적으로 CPU주기가 덜 필요합니다. 예를 들어 ①, 정수는 문자 연산보다 저렴합니다. 문자 집합과 조합 규칙은 문자 비교가 정수 비교보다 더 복잡하기 때문입니다. ②, mysql Self를 사용합니다. -날짜와 시간을 저장하기 위해 문자열 대신에 빌드 된 타입; ③, IP 주소를 저장하기 위해 정수를 사용합니다.

null을 피하십시오 : 쿼리에 NULL이 될 수있는 열이 포함 된 경우 null이 될 수있는 열이 인덱스, 인덱스 통계 및 값 비교를 더 복잡하게 만들기 때문에 mysql을 최적화하기가 어렵습니다. null이 아님으로 변경하여 가져온 성능 향상은 상대적으로 작으므로 모든 테이블의 스키마를 수정할 필요는 없지만 null이 될 수있는 열은 디자인하지 않도록해야합니다. ㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ

실제 규칙 :

2. 패러다임과 반 패러다임의 공정한 사용

①, 패러다임

이점:

정규화 업데이트는 일반적으로 안티 패러다임보다 빠릅니다.
데이터가 더 잘 정규화되면 중복 데이터가 거의 또는 전혀 없습니다.
정규화 된 데이터는 상대적으로 작으며 메모리에 저장할 수 있으며 작업이 더 빠릅니다.

단점 :

일반적으로 연결되어야 함

②, 반 패러다임

이점

모든 데이터가 동일한 테이블에 있으므로 연결을 피할 수 있습니다.
효과적인 색인을 설계 할 수 있습니다.

불리

테이블에는 많은 중복성이 있으며 데이터가 삭제되면 테이블의 일부 유용한 정보가 손실됩니다.

③주의

반복 된 실패 후에 저는이 백만 자의 "MySQL 성능 조정 노트"를 요약했습니다.

3. 기본 키 선택

대리 기본 키 : 업무와 관련이없는 의미없는 일련의 숫자

자연적인 기본 키 : 사물의 속성에있는 자연적인 고유 식별자

대리 기본 키를 사용하는 것이 좋습니다.

비즈니스와 연결되어 있지 않으므로 유지 관리가 더 쉽습니다.
다수의 테이블, 가급적이면 모든 테이블, 공통 키 전략은 작성해야하는 소스 코드의 양을 줄이고 시스템의 총 소유 비용을 줄일 수 있습니다.

4. 스토리지 엔진 선택

반복 된 실패 후에 저는이 백만 자의 "MySQL 성능 조정 노트"를 요약했습니다.

5. 적절한 데이터 중복

자주 인용되고 2 개 이상의 큰 테이블을 조인해야만 얻을 수있는 독립적 인 작은 필드.
이러한 시나리오에서 Join은 매번 작은 필드의 값을 얻기위한 것이고 Join의 레코드가 너무 커서 불필요한 IO가 많이 발생하여 시간에 대한 대가로 공간에 의해 최적화 될 수 있습니다. 그러나 중복성이있는 동안 데이터의 일관성이 손상되지 않도록하고 중복 필드도 업데이트 중에 업데이트되도록해야합니다.

6. 올바르게 분할

테이블에 TEXT와 유사한 큰 필드 또는 매우 큰 VARCHAR 유형이있는 경우이 테이블에 대한 대부분의 액세스에이 필드가 필요하지 않은 경우에는이를 별도의 테이블에서 다른 테이블로 분할하여 차지하는 저장 공간을 줄여야합니다. 자주 사용되는 데이터. 이것의 명백한 이점은 각 데이터 블록에 저장할 수있는 데이터 항목의 수가 크게 증가 할 수 있다는 것입니다. 이는 물리적 IO의 수를 줄일뿐만 아니라 메모리의 캐시 적중률을 크게 향상시킵니다.

세, 구현 계획

넷째, 인덱스를 통한 최적화

1. 인덱싱에 대한 기본 지식

인덱싱의 장점
색인의 유용성
인덱스 분류
인터뷰 기술 용어
인덱스에서 사용하는 데이터 구조
인덱스 매칭 방법

2. 해시 인덱스

해시 테이블 구현에 따라 인덱스의 모든 열과 정확히 일치하는 쿼리 만 유효합니다.
mysql에서는 메모리 스토리지 엔진 만 명시 적으로 해시 인덱스를 지원합니다.
해시 인덱스 자체는 해당하는 해시 값만 저장하면되므로 인덱스 구조가 매우 콤팩트하여 해시 인덱스 조회가 매우 빨라집니다. ㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ ㅇㅇㅇ
무료 테마

3. 결합 된 색인

여러 열이 인덱스로 포함되는 경우 올바른 순서는 인덱스 쿼리에 따라 다르며 정렬 및 그룹화 요구 사항을보다 잘 충족 할 수있는 방법을 고려해야합니다.

4. 클러스터형 인덱스 및 비 클러스터형 인덱스

클러스터형 인덱스 : 별도의 인덱스 유형이 아니라 인접한 키 값이있는 데이터 행의 압축 저장을 참조하는 데이터 저장 방법입니다.
비 클러스터형 인덱스 : 데이터 파일은 인덱스 파일과 별도로 저장됩니다.

5. 커버링 인덱스

기본 소개
이점

6. 작은 세부 사항 최적화

쿼리에 인덱스 열을 사용할 때는 식을 사용하지 말고 데이터베이스 계층 대신 비즈니스 계층에 계산을 넣으십시오.
다른 인덱스 대신 기본 키 쿼리를 사용하여 기본 키 쿼리가 테이블 쿼리로 다시 트리거되지 않도록하십시오.
접두사 색인 사용
인덱스 스캔을 사용하여 정렬
모두, in 또는 인덱스를 사용할 수 있지만 in이 권장됩니다.
범위 열은 인덱스를 사용할 수 있습니다.
강제 유형 변환은 전체 테이블을 스캔합니다.
업데이트가 매우 빈번하며 데이터 차별성이 낮은 필드에는 인덱싱이 적합하지 않습니다.
인덱스 열을 만듭니다. null 일 수 없습니다. 기대에 미치지 못하는 결과를 얻을 수 있습니다.
테이블을 조인해야하는 경우 조인해야하는 필드의 데이터 유형이 일관 적이어야하므로 테이블 3 개를 초과하지 않는 것이 가장 좋습니다.
한계를 사용할 수있을 때 한계를 사용하십시오.
단일 테이블 인덱스는 5 개 이내로 제어하는 것이 좋습니다.
단일 색인 필드의 수는 5 (결합 색인)를 초과 할 수 없습니다.
인덱스를 생성 할 때 다음과 같은 오해를 피해야합니다.

7. 인덱스 모니터링

반복 된 실패 후에 저는이 백만 자의 "MySQL 성능 조정 노트"를 요약했습니다.

다섯, 쿼리 최적화

1. 쿼리가 느린 이유

인터넷
CPU
나는
컨텍스트 전환
시스템 호출
통계 생성
잠금 대기 시간

2. 데이터 액세스 최적화

쿼리 성능이 떨어지는 주된 이유는 너무 많은 데이터에 액세스 할 수 없기 때문입니다. 일부 쿼리는 필연적으로 많은 양의 데이터를 필터링해야합니다. 액세스하는 데이터의 양을 줄여 최적화 할 수 있습니다.

데이터베이스에서 불필요한 데이터를 요청 했습니까?

원하지 않는 레코드 쿼리
여러 테이블이 연결된 경우 모든 열 반환
항상 모든 열 가져 오기
동일한 데이터를 반복적으로 쿼리

3. 실행 프로세스의 최적화

쿼리 캐시 : 쿼리 문을 구문 분석하기 전에 쿼리 캐시가 켜져 있으면 mysql은 먼저 쿼리가 쿼리 캐시에있는 데이터를 적중하는지 확인합니다. 쿼리가 쿼리 캐시에 적중하면 쿼리를 반환하기 전에 사용자 권한을 확인합니다. result, 권한에 문제가 없으면 mysql은 모든 단계를 건너 뛰고 캐시에서 직접 결과를 가져와 클라이언트에 반환합니다.

쿼리 최적화 처리 : mysql이 캐시를 쿼리 한 후 SQL 구문 분석, 전처리 및 SQL 실행 계획 최적화 단계를 거칩니다.이 단계에서 오류가 발생하면 쿼리가 종료 될 수 있습니다.

4. 특정 유형의 쿼리 최적화

count () 쿼리 최적화
관련 쿼리 최적화
하위 쿼리 최적화
제한 페이징 최적화
통합 쿼리 최적화
사용자 정의 변수 사용 권장

여섯, 파티션 테이블

1. 파티션 테이블의 적용 시나리오

테이블이 너무 커서 메모리에 모두 저장할 수 없거나 테이블의 마지막 부분에만 핫 데이터가 있고 나머지는 기록 데이터입니다.
파티션 테이블 데이터는 유지 관리가 더 쉽습니다.
파티션 테이블의 데이터는 서로 다른 물리적 장치에 분산되어 여러 하드웨어 장치를 효율적으로 사용할 수 있습니다.
파티션 테이블을 사용하여 특별한 병목 현상을 방지 할 수 있습니다.
독립 파티션을 백업 및 복원 할 수 있습니다.

2. 파티션 테이블의 한계

테이블에는 최대 1024 개의 파티션 만있을 수 있으며 버전 5.7에서는 8196 개의 파티션이 지원 될 수 있습니다.
초기 MySQL에서는 파티션 표현식이 정수이거나 정수를 반환하는 표현식이어야합니다. MySQL 5.5에서는 일부 시나리오에서 파티션을 위해 열을 직접 사용할 수 있습니다.
파티션 필드에 기본 키 또는 고유 인덱스 열이있는 경우 모든 기본 키 열과 고유 인덱스 열이 포함되어야합니다.
파티션을 나눈 테이블은 외래 키 제약 조건을 사용할 수 없습니다.

3. 파티션 테이블의 원리

반복 된 실패 후에 저는이 백만 자의 "MySQL 성능 조정 노트"를 요약했습니다.

4. 파티션 테이블의 종류

범위 파티션
목록 파티션
열 파티션
해시 파티션
키 파티션
하위 파티션

5. 파티션 테이블 사용 방법

매우 큰 테이블에서 특정 기간의 레코드를 쿼리해야하고이 테이블에 다년간의 기록 데이터가 포함되어있는 경우 데이터가 시간별로 정렬됩니다. 이때 데이터를 쿼리하는 방법은 무엇입니까?

엄청난 양의 데이터 때문에 쿼리 할 때마다 전체 테이블을 스캔하는 것은 확실히 불가능합니다. 인덱스의 공간과 유지 보수를 고려할 때 인덱스를 사용하고 싶지 않습니다. 인덱스를 사용하더라도 많은 양의 조각화가 발생하고 많은 양의 임의 IO가 발생한다는 것을 알 수 있습니다. 그러나 데이터의 양이 너무 많으면 인덱스가 작동하지 않습니다. 기능, 이때 파티션을 사용하여 해결하는 것을 고려할 수 있습니다.

6. 파티션 테이블 사용시주의해야 할 사항