Mysql 문 분석, 스토리지 엔진, 인덱스 최적화 및 기타 세부 정보

고성능 MySQL 읽기 노트

MySQL 스토리지 엔진

Mysql의 기본 스토리지 엔진 : Innodb

Mysql5.1 버전 이전의 기본 스토리지 엔진은 MyISAM 입니다.

스토리지 엔진의 다중 동시성 제어 차이(MVCC):

이노디비：

네 가지 격리 수준을 사용하여 트랜잭션 지원

1. 커밋되지 않은 읽기(커밋되지 않은 읽기)

   가장 높은 동시성, 트랜잭션의 수정 사항이 제출되더라도 다른 트랜잭션에서 볼 수 있음

2. 커밋된 읽기

   대부분의 데이터베이스 관리 시스템의 기본 격리 수준은 이것(Mysql은 아님)이며 커밋된 트랜잭션 수정만 볼 수 있습니다.

   두 실행의 결과는 같지만 결과가 다를 수 있습니다.

3. RepeatTable 읽기(반복 가능한 읽기)
   Mysql 트랜잭션 기본 격리 수준입니다. 동일한 트랜잭션의 여러 읽기 결과가 일관성이 있는지 확인

4. 직렬화 가능(직렬화 가능)

가장 높은 격리 수준, 가장 낮은 동시성은 데이터의 각 행을 읽을 때 공유 잠금을 추가합니다.

MyISAM：

거래를 지원하지 않습니다

성능 측면에서 MyISAM은 일부 특정 시나리오에서 잘 작동합니다. 디자인이 단순하고 데이터가 컴팩트한 형식으로 저장되며 삽입 속도가 매우 빠름

MySQL 자동 커밋

Mysq는 기본적으로 자동 커밋 모드를 사용합니다. 즉, 트랜잭션이 명시적으로 열리지 않으면 각 쿼리를 트랜잭션으로 처리하여 커밋 작업을 수행합니다. 현재 링크에서 AUTOCOMMIT 변수를 설정하여 자동 커밋 모드를 활성화하거나 비활성화할 수 있습니다. (*10)

set autocommit= 0/1(1: 활성화. 0: 비활성화) 명령을 전달할 수 있습니다.

MySQL 성능 분석

Mysql 쿼리를 로그 파일로 캡처

long_query_time=0으로 설정하면 모든 쿼리를 캡처할 수 있습니다.

show variables like 'slow_query_log'; -- 显示是否开启慢sql日志
SET GLOBAL slow_query_log_file	-- 指定慢查询日志存储文件的地址和文件名。
SET GLOBAL log_queries_not_using_indexes	-- 无论是否超时，未被索引的记录也会记录下来。
SET SESSION long_query_time	-- SQL 执行超过这个阈值(秒)将被记录在日志中。
SET SESSION min_examined_row_limit	-- 慢查询仅记录扫描行数大于此参数的 SQL。

느린 쿼리 로그를 분석하기 위한 도구 pt-query-digest가 있습니다. 절반의 경우, 제대로 작동하려면 느린 쿼리 로그를 매개변수로 pt-query-digest 에 전달하기만 하면 됩니다 . 그는 쿼리의 분석 보고서를 인쇄합니다.

MySQL 성능 분석 도구

1. New Relic (프로파일링을 위해 애플리케이션에 연결됨)
2. Mathkit
3. Super Smark (스트레스 테스트 및 부하 생성 제공 가능. 테스트 데이터를 데이터베이스에 로드할 수 있으며 생성된 데이터를 축적하여 데이터 테이블을 채울 수 있음)

프로필 보기

진술 분석 도구

SHOW PROFILE 명령은 Mysql5.1 이후 버전에서 도입되었습니다. 기본적으로 비활성화되어 있으며 set profiling=1활성화 할 수 있습니다.

서버에서 도구에 의해 실행되는 모든 명령문은 경과 시간 및 기타 쿼리 실행 상태 변경 관련 데이터를 감지합니다.

쿼리 명령이 서버에 제출되면 분석 정보가 임시 레코드 테이블에 기록됩니다.

사용하는 방법:

show PROFILES 명령을 사용하여 기록된 모든 실행 문을 확인하고 각 문에는 코드 Query_id가 있습니다. 세부 정보를 보려는 명세서를 찾습니다. Query_id를 가져옵니다.

순서대로

show profile for QUERY queri_id(위에서 얻은 Query_id);

아래 그림과 같이

상태 표시

작업 수를 표시하는 일부 카운터를 반환합니다. 예를 들어 다음 SQL 문에서 임시 테이블이 사용되는 횟수를 빠르게 볼 수 있습니다. 색인(*84)을 사용한 읽기 작업

SHOW STATUS WHERE Variable_name	LIKE 'Handler%' OR Variable_name LIKE 'Create%'

SHOW GLOBAL STATUS를 사용하여 글로벌 상태를 표시할 수도 있습니다.

최적화된 데이터 유형 선택

주의점

1. 일반적으로 더 작은 데이터 유형은
2. 예를 들어, 성형 작업 비용이 문자열 작업 비용보다 낮습니다.
3. NULL 값을 피하십시오

칼럼은 NOT NULL로 지정하는 것이 가장 좋으며 쿼리에 NULL 값이 포함되어 있으면 Mysql에 최적화하기가 더 어려울 수 있다. NULLable 열은 인덱스, 인덱스 통계 및 값 비교를 복잡하게 하기 때문에 NULLable 열은 더 많은 저장 공간을 사용합니다.

정수 유형

정수를 저장하는 경우 여러 가지 정수 유형이 있습니다.

자동 증분을 사용하는 것도 좋습니다.

1. TINYINT 범위: (-128-127) 점유 바이트: 8
2. SMALLINT 범위: (-8388608-8388607) 16
3. MEDIUMINT 범위: (-128-127) 24
4. 지능 범위: (-2,147,483,648-2,147,483,647) 32
5. BIGINT 범위: (-9223372036854775808-9223372036854775807) 64

부동 소수점 유형

1. 소수

   BIGINT보다 큰 정수를 저장할 수 있고 고정밀 계산을 지원할 수 있습니다.

2. 더블

3. 뜨다

문자열 유형

1. VARCHAR

가변 길이 문자열, 문자 길이를 기록하려면 추가 바이트가 필요합니다.

생각 :

varchar(5)와 varchar(2000)은 공간 오버헤드가 같으므로 더 짧은 열을 사용하면 어떤 이점이 있습니까?

답: 큰 장점이 있을 것이고, mysql이 내부 천 값을 저장하기 위해 고정된 크기의 메모리를 할당하기 때문에 더 많은 메모리를 절약할 것입니다.

.我们只需要分配真正需要的空间为最佳

2. 숯

고정 길이의 문자를 저장할 때 사용 문자를 저장할 때 끝의 모든 공백이 삭제됨 필드의 길이에 가까운 값을 저장하는 데 적합

대용량 데이터 유형

1. 볼브. (바이너리 형식으로 데이터 저장)
2. 텍스트. (문자 형식으로 데이터 저장)

날짜 시간 유형

1. 날짜 시간

고정된 형식으로 YYYYMMDDHHMMSS 정수로 저장(1001~9999까지 저장 가능)

2. 타임스탬프

   1970년부터 2038년까지만 저장 가능, 타임스탬프를 사용하여 시간 데이터 저장

인덱스 베이스

인덱싱의 장점

1. 서버가 스캔해야 하는 데이터의 양을 크게 줄입니다.
2. 서버가 임시 테이블 및 정렬을 피하도록 도와줍니다.
3. Random IO는 순차적 IO로 변경 가능

B-트리

Mysql의 인덱스 데이터 유형은 B-Tree 데이터 구조를 사용하여 구현됩니다.

b-tree는 일반적으로 모든 값이 순차적으로 저장됨을 의미합니다.

인덱스 유형

1. 단일 값 지수

만드는 방법:

create index [indexname] ON [tablename](fieldname)

가장 일반적인 색인. 열의 모든 값에 대해 b-tree 인덱스 트리를 생성하고 오름차순으로 정렬

2. 고유지수와 공동고유지수

ALTER TABLE tablename  ADD  UNIQUE [indexname] (fieldname,fieldname)

인덱싱된 열 값은 고유해야 합니다. 그러나 null 일 수 있습니다

3. 공동지수

create index [indexname] ON [tablename](fieldname,fieldname)

여러 열을 인덱스 값으로 지정하고 여러 열을 동시에 오름차순으로 정렬할 수 있습니다. 맨 왼쪽 매칭 원칙을 따라야 함

5천만 개 이상의 레코드가 있는 테이블. 다음 두 사진을 통해 동일한 sql. 하나는 공동 인덱스를 추가하고 인덱스를 덮습니다. 하나는 색인이 없습니다. 시간 비교는 인덱스의 최적화 효율성을 보여줄 수도 있습니다.

4. 접두어 색인

ALTER TABLE table_name ADD KEY(column_name(prefix_length));

일부 필드의 길이가 매우 크거나 공간이 큰 필드 유형 열인 경우. 접두사 색인 사용에 적합, 색인 파일 크기 감소, 색인 제출 속도 감소

때로는 매우 긴 문자 열이 인덱싱되어 인덱스가 크고 느려질 수 있습니다. 일반적으로 첫 번째 부분 문자를 인덱싱할 수 있습니다. 이렇게 하면 인덱스 공간을 크게 절약할 수 있으므로 인덱스 효율성이 향상되고 인덱스 선택도 줄어듭니다(동일한 인덱스 값에 여러 데이터 행이 포함될 수 있음).

order by 및 group by와 함께 사용할 수 없습니다. 커버링 인덱스로도 사용할 수 없습니다.

5. 클러스터형 인덱스

클러스터형 인덱스 외에 다른 보조 인덱스는 行指针행의 기본 키를 저장하고 기본 키를 찾은 다음 기본 키의 클러스터형 인덱스를 통해 테이블로 돌아가 행 데이터를 찾습니다.

다른 인덱스와의 가장 큰 차이점은 인덱스와 데이터가 같은 영역에 존재하며, 인덱스가 있으면 데이터를 찾을 수 있다는 것입니다. 데이터 테이블의 기본 키는 클러스터형 인덱스입니다. 테이블을 생성할 때 기본 키가 기본적으로 지정되지 않은 경우 mysql의 스토리지 엔진 Innodb는 비어 있지 않은 고유한 인덱스를 대신 선택합니다. 그러한 인덱스가 없으면 InnoDB는 묵시적으로 기본 키를 클러스터형 인덱스로 정의합니다.

6. 커버링 인덱스

추가할 수 있는 특정 인덱스가 아니라 쿼리하려는 모든 데이터 열과 쿼리 조건이 해당 인덱스를 사용한다는 의미입니다. 기본 키를 통해 데이터를 쿼리하기 위해 더 이상 테이블로 돌아갈 필요가 없습니다. 즉, 쿼리 열이 인덱스 열과 일치합니다.

커버링 인덱스는 효과적으로 IO를 줄이고 쿼리 효율성을 향상시킬 수 있습니다.

쓸모 없는.

Select *

다음 테이블에는 select *인덱스 필드를 사용하는 5천만 개의 테스트 데이터가 있습니다. 쿼리 시간의 비교는 n의 차이가 있습니다. 이것이 커버링 인덱스의 이점입니다. 동시에 사용을 피하십시오.Select *

인덱스 실패 시나리오

1. 공동 인덱스가 가장 왼쪽 일치 원칙을 충족하지 않습니다.
2. 사용select *
3. 인덱스 열이 함수 계산에 참여
4. 123%이러한 종류의 다른 퍼지 쿼리 외에도 . %123, %123%실패합니다
5. 유형 암시적 변환
6. 인덱스 열 간 비교
7. 사용 조건이 존재하지 않음, 존재하지 않음, null이 아님