잘 알려지지 않은 10가지 SQL 문 최적화

1. 일부 일반적인 SQL 관행

(1) 부정적인 조건부 쿼리는 색인을 사용할 수 없습니다.

》

은 쿼리에서 최적화할 수 있습니다:

select * from order where status!=0 and stauts!=1

(2) 선행 퍼지 쿼리는 인덱스를 사용할 수 없습니다.

select * from order where status in(2,3)

선행하지 않는 퍼지 쿼리는 사용할 수 있습니다:

select * from order where desc like '%XX'

(3) 데이터 차별화가 거의 없는 필드는 적합하지 않습니다. 이유 인덱스 사용을 위한

select * from order where desc like 'XX%'

: 성별은 남성과 여성만 있고, 매번 필터링되는 데이터의 양이 적어 인덱스를 사용하는 것은 적절하지 않습니다.

경험에 따르면, 데이터의 80%를 필터링할 수 있을 때 인덱스를 사용할 수 있습니다. 주문 상태의 경우 상태 값이 적다면 인덱스를 사용하는 것이 적절하지 않으며, 상태 값이 많아 필터링할 수 있는 데이터가 많은 경우 인덱스를 설정해야 한다.

(4) 속성 계산은 인덱스에 도달할 수 없습니다

select * from user where sex=1

날짜에 인덱스가 생성되더라도 테이블 전체를 스캔하므로 값 계산에 최적화될 수 있습니다:

select * from order where YEAR(date) < = &#39;2017&#39;

또는:

select * from order where date < = CURDATE()

2. 잘 알려지지 않은 SQL 실습

(5) 대부분의 비즈니스가 단일 쿼리인 경우 사용자 센터와 같이 Hash 인덱스를 사용하는 성능이 더 좋습니다

select * from order where date < = &#39;2017-01-01&#39;

이유:

B-Tree 인덱스의 시간 복잡도 is O(log(n))

해시 인덱스의 시간 복잡도는 O(1)

(6) 열이 null이 허용되면 쿼리에 잠재적인 함정이 있습니다

단일 열 인덱스는 저장하지 않습니다 null 값이 허용되며 복합 인덱스는 모든 null 값을 저장하지 않습니다. 열이 null이 허용되면 "예기치 않은" 결과 집합이 나타날 수 있습니다.

select * from user where uid=?
select * from user where login_name=?

name이 null이 허용되면 인덱스는 null 값을 저장하지 않습니다. 이며 이러한 레코드는 결과 세트에 포함되지 않습니다.

따라서 null이 아닌 제약 조건과 기본값을 사용하세요.

(7) 복합 인덱스의 가장 왼쪽 접두사는 값 SQL 문의 where 순서가 복합 인덱스와 일치해야 한다는 의미는 아닙니다.

사용자 센터에서는 (login_name, passwd)

select * from user where name != 'shenjian'

복합 인덱스를 설정했습니다. 인덱스에 적중할 수 있음

select * from user where login_name=? and passwd=?
select * from user where passwd=? and login_name=?

도 인덱스에 적중하고 복합 인덱스의 가장 왼쪽 접두사를 충족

select * from user where login_name=?

인덱스에 적중할 수 없으며 복합 인덱스의 가장 왼쪽 접두사를 충족하지 않음

(8) 문자열 대신 ENUM 사용

ENUM은 TINYINT를 저장합니다. 열거형에 일부 ""를 사용하지 마세요. "China", "Beijing" 및 "Ministry of Technology"와 같은 문자열은 문자열 공간이 크고 효율성이 낮습니다.

3. 틈새지만 유용한 SQL 연습

(9) 하나의 결과만 반환된다는 것을 알고 있는 경우 제한 1은 효율성을 향상시킬 수 있습니다.

select * from user where passwd=?

최적화할 수 있습니다:

select * from user where login_name=?

이유:

알고 계시는 대로 하나의 결과일 뿐인데 데이터베이스는 알지 못하므로 명확하게 알려주고 적극적으로 커서 이동을 중지하도록 하세요

(10) 데이터의 CPU를 절약하는 것 외에도 데이터베이스 계층 대신 비즈니스 계층에 계산을 넣습니다. 예상치 못한 쿼리 캐시 최적화 효과도 있습니다

select * from user where login_name=? limit 1

이는 좋은 SQL 관행이 아니며 다음과 같이 최적화되어야 합니다.

select * from order where date < = CURDATE()

이유:

는 데이터베이스의 CPU를 해제합니다.

다중 호출, 동일한 수신 SQL을 사용하여 다음 작업을 수행할 수 있습니다. 쿼리 캐시를 활용하세요

(11) 강제 유형 변환은 Full table scan

$curDate = date('Y-m-d');
$res = mysql_query(
    &#39;select * from order where date < = $curDate&#39;);

폰 인덱스에 닿을 것 같나요? 이것은 큰 실수입니다. 이 말을 어떻게 바꿀 수 있습니까?

마지막으로 한 가지 더, select *를 사용하지 않고 필요한 열만 반환하면 데이터 전송량과 데이터베이스의 메모리 사용량을 크게 절약할 수 있습니다.

이 기사는 PHP 중국어 웹사이트,

mysql tutorial

칼럼에서 가져온 것입니다. 배우신 것을 환영합니다!

위 내용은 잘 알려지지 않은 10가지 SQL 문 최적화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!