MySQL
MySQL의 성능 팁

명령문 최적화 선택

다음은 우리가 쿼리 시간을 줄이는데 도움이되는 MySQL의 선택 쿼리를 작성하는 동안 기억해야 할 몇 가지 팁입니다.

1. 우리가 큰 테이블에서 where를 사용할 때마다 where 절의 컬럼이 인덱스인지 아닌지 확인해야합니다. 예 : - employee_id> 2000 인 user_id를 인덱스에서 선택하면 employee_id에서 *를 선택하면 쿼리 atlot의 평가 속도가 빨라집니다. 조인과 외래 키 중에 인덱스도 매우 중요합니다.

2. 테이블에서 전체 데이터를 가져 오는 대신 내용의 더 작은 섹션이 필요한 경우 제한을 사용해보십시오. 대신 Ex : - Employee에서 *를 선택하십시오. lakhs에서 처음 20 명의 직원이 필요하면 limit Ex : - LIMIT 20 직원을 선택하십시오.

3. 또한 결과 집합에 원하는 열 이름을 제공하여 쿼리를 최적화 할 수도 있습니다. 대신 Ex : - Employee에서 *를 선택하십시오. 테이블에 많은 열이 있고 그 중 일부에 대한 데이터 만 갖고 싶다면 데이터가 필요한 열 이름을 언급하십시오. 예 : - 직원의 아이디, 이름을 선택하십시오.

4. where 절에서 NULL을 확인하는 데 사용하는 경우 인덱스 열. SELECT * FROM tbl_name where key_col이 NULL 인 문장을 가지고 있다면; key_col이 인덱싱되면 쿼리가 더 빨리 평가됩니다.

InnoDB 테이블을위한 스토리지 레이아웃 최적화

1. InnoDB에서 긴 PRIMARY KEY (긴 값을 가진 단일 열 또는 긴 복합 값을 형성하는 여러 열)를 사용하면 많은 디스크 공간이 낭비됩니다. 행의 기본 키 값은 동일한 행을 가리키는 모든 2 차 인덱스 레코드에서 복제됩니다. 기본 키가 긴 경우 AUTO_INCREMENT 열을 기본 키로 만듭니다.
2. CHAR 대신 VARCHAR 데이터 유형을 사용하여 가변 길이 문자열이나 많은 NULL 값이있는 열을 저장하십시오. CHAR (N) 열은 문자열이 더 짧거나 값이 NULL 인 경우에도 데이터를 저장하기 위해 항상 N자를 사용합니다. 더 작은 테이블은 버퍼 풀에서 더 잘 맞고 디스크 I / O를 줄입니다.

COMPACT 행 형식 (기본 InnoDB 형식)과 utf8 또는 sjis와 같은 가변 길이 문자 집합을 사용할 때 CHAR (N) 열은 가변적 인 공간을 차지하지만 N 바이트 이상을 차지합니다.

3. 큰 테이블 또는 반복되는 텍스트 또는 숫자 데이터가 많이 들어있는 경우 COMPRESSED 행 형식 사용을 고려하십시오. 데이터를 버퍼 풀로 가져 오거나 전체 테이블 스캔을 수행하는 데 필요한 디스크 I / O는 적습니다. 영구 결정을 내리기 전에 COMPRESSED 대 COMPACT 행 형식을 사용하여 얻을 수있는 압축 량을 측정하십시오. 주의 사항 : 벤치 마크는 2 : 1 압축보다 성능이 좋지 않으며 압축을 위해 buffer_pool에 많은 오버 헤드가 있습니다.
4. 데이터가 안정된 크기에 도달하거나 증가하는 테이블이 수십 또는 수백 메가 바이트 증가하면 OPTIMIZE TABLE 문을 사용하여 테이블을 재구성하고 낭비되는 공간을 압축하십시오. 재구성 된 테이블은 전체 테이블 스캔을 수행하는 데 필요한 디스크 입출력이 적습니다. 이것은 색인 사용 개선이나 응용 프로그램 코드 조정과 같은 다른 기술이 실용적이지 않은 경우 성능을 향상시킬 수있는 간단한 기술입니다. 주의 사항 : 테이블 크기에 관계없이 OPTIMIZE TABLE은 거의 수행되지 않아야합니다. 이것은 비용이 많이 들고, 가치있는 테이블을 거의 향상시키지 않기 때문입니다. InnoDB는 B + Trees를 많은 낭비 공간으로부터 자유롭게 유지하는 데 상당히 능숙합니다.

OPTIMIZE TABLE은 테이블의 데이터 부분을 복사하고 인덱스를 다시 작성합니다. 그 이점은 인덱스 내에서의 데이터 패키징 향상과 테이블 공간 및 디스크 내에서의 단편화 감소로 인한 것입니다. 이점은 각 테이블의 데이터에 따라 다릅니다. 일부 사용자에게는 큰 이익이 있고 다른 사용자에게는 큰 이익이 없다는 것을 알게되거나 다음에 테이블을 최적화 할 때까지 시간이 지남에 따라 이익이 감소한다는 것을 알 수 있습니다. 테이블이 크거나 재 빌드중인 인덱스가 버퍼 풀에 맞지 않으면이 조작은 @ 리게됩니다. 많은 양의 데이터를 테이블에 추가 한 후 첫 번째 실행은 종종 나중에 실행하는 것보다 훨씬 느립니다.

복합 색인 작성

많은 경우, 복합 인덱스는 단일 C 럼이있는 인덱스보다 성능이 우수합니다. 최적의 합성 색인을 작성하려면이 순서대로 열을 채 웁니다.

• = WHERE 절의 컬럼. (예 : INDEX(a,b,...) 는 WHERE a=12 AND b='xyz' ... )
• IN 열 (들); 옵티마이 저가 인덱스를 통해 뛰어 넘을 수 있습니다.
• 하나의 "range"(예 : x BETWEEN 3 AND 9 , name LIKE 'J%' ) 첫 번째 범위 열을 지나서는 아무 것도 사용하지 않습니다.
• GROUP BY 모든 열을 순서대로
• ORDER BY 모든 열을 순서대로 표시합니다. 모두 ASC 이거나 모두 DESC 이거나 8.0을 사용하는 경우에만 작동합니다.

메모 및 예외 사항 :

• 컬럼을 복제하지 마십시오.
• 적용되지 않는 경우 건너 뜁니다.
• WHERE 모든 열을 사용하지 않으면 GROUP BY 등으로 이동할 필요가 없습니다.
• WHERE 무시하고 ORDER BY 열만 인덱싱하는 것이 유용한 경우가 있습니다.
• 함수에서 열을 "숨기지"마십시오 (예 : DATE(x) = ... 색인에서 x 를 사용할 수 없음).
• '접두사'색인 생성 (예 : text_col(99) )은 도움이되지 않습니다. 상처받을 수 있습니다.

자세한 내용 및 팁 .