SQL 성능 최적화

머리말: 오늘은 더욱 중요한 이슈인 SQL 성능 최적화에 대해 소개해드리겠습니다.

데이터베이스를 운영할 때 어떻게 SQL 문을 더 효율적으로 만드는지는 매우 중요한 문제입니다. 아래에서는 성능 최적화 문제를 요약해 보겠습니다.

SQL 성능 최적화

1 SELECT 문은 필드 이름을 지정해야 합니다.

# 🎜🎜 #SELECT *는 불필요한 소비(CPU, IO, 메모리, 네트워크 대역폭)를 많이 증가시킵니다.

테이블 구조가 변경되면 정방향 중단도 수행됩니다. 갱신이 필요합니다. 따라서 선택 후 필드명을 직접 추가해야 합니다.

2. SQL 문에서 IN에 포함된 값은 너무 많지 않아야 합니다.

MySQL에서는 IN에 대해 해당 최적화를 수행했습니다. 즉, IN의 모든 상수가 저장됩니다. 그리고 이 배열은 정렬되어 있습니다.

하지만 값이 크면 소비도 상대적으로 커지게 됩니다. 연속형 값의 경우 between을 사용하거나 대신 연결을 사용할 수 있으면 in을 사용하지 마세요.

3. in과 존재하지 않음을 구별합니다.

select * from 表A 
where id in (select id from 表B)

은

select * from 表A 
where exists(select * from 表B where 表B.id=表A.id)

#의 구별과 동일합니다. 🎜🎜# in 및 존재는 주로 구동 순서 변경을 유발합니다(이것이 성능 변경의 핵심입니다). 존재하는 경우 외부 테이블이 구동 테이블이며 IN인 경우 하위 쿼리에 먼저 액세스됩니다. 먼저 실행됩니다.

So IN은 외부 표면은 크지만 내부 표면은 작은 상황에 적합하고 EXISTS는 외부 표면은 작지만 내부 표면은 큰 상황에 적합합니다.

4. % 접두사 퍼지 쿼리는 사용하지 않는 것이 좋습니다.

예: LIKE "%name" 또는 LIKE "%name% ", 이러한 종류의 쿼리는 인덱스 실패를 유발하고 전체 테이블 스캔을 수행합니다. 그러나 LIKE "name%"는 사용할 수 있습니다.

암시적 유형 변환 방지:

Wher 절의 열 필드 유형이 수신 매개변수 유형과 일치하지 않는 경우 발생합니다. 유형 변환의 경우, where

5에서 매개변수 유형을 먼저 결정하는 것이 좋습니다. 조인트 인덱스의 경우 가장 왼쪽 접두사 규칙

을 따릅니다. , 인덱스에는 id, name 및 school 필드가 포함됩니다. id 필드를 직접 사용하거나 id, name 순서를 사용할 수 있지만 학교는 이 인덱스를 사용할 수 없습니다.

따라서 공동 인덱스를 생성할 때는 일반적으로 사용되는 쿼리 필드가 먼저 배치되는 순서에 주의해야 합니다.

위 내용을 요약하면 다음과 같습니다. 제안 사항:

1. 인덱스 필드에서 계산 작업을 피하세요.

2 not <>

3 . 인덱스 필드

3에서 is null, is null을 사용하지 마세요. 인덱스 필드에서 데이터 유형 변환을 피하세요 #🎜 🎜##. 🎜🎜#5. 인덱스 열

6에 Null 값을 사용하지 마세요. WHERE

7에 대한 문 규칙은 WHERE 절에 Null 값을 사용하지 마세요. in, not in 또는 have를 사용하거나, in, not in

8 대신에existence, not presents를 사용할 수 있습니다. 숫자 형식으로 숫자를 선언하지 말고, 숫자 형식으로 문자 값을 선언하지 마세요. 그렇지 않으면 색인이 유효하지 않습니다. # 🎜🎜#

위의 질문은 모든 사람을 위해 요약된 것입니다. 더 많은 질문이 있으면 PHP 중국어 웹사이트(

https://www.php)에서 해당 튜토리얼을 방문하세요. cn/course/list/51/type/2 .html

위 내용은 SQL 성능 최적화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!