>  기사  >  백엔드 개발  >  MySQL 쿼리 최적화

MySQL 쿼리 최적화

WBOY
WBOY원래의
2016-12-01 00:56:511008검색

Mysql 쿼리에서 특정 필드 packageId(기본 키 아님) = num의 결과를 필터링하려면 not in을 직접 사용하는 것이 더 낫습니까, 아니면 쿼리가 완료되고 결과 세트가 순회됩니다. 쿼리가 완료된 후에는 무슨 일이 있어도 결과 집합을 순회해야 합니다. MySQL 쿼리 최적화

답글 내용:

Mysql 쿼리에서 특정 필드 packageId(기본 키 아님) = num의 결과를 필터링하려면 not in을 직접 사용하는 것이 더 낫습니까, 아니면 쿼리가 완료되고 결과 세트가 순회됩니다. 쿼리가 완료된 후에는 무슨 일이 있어도 결과 집합을 순회해야 합니다. MySQL 쿼리 최적화

피험자가 댓글에 질문을 추가했습니다

우리가 고려하는 것은 인덱스 때문입니다<> 이러한 유형의 쿼리 조건은 인덱스를 사용하지 않으며 전체 테이블 쿼리 속도가 매우 느려집니다. 그러나 이 작업에 필요한 데이터의 양은 여전히 ​​매우 많습니다. 해당 사이트의 일부 패키지 이용자에게 알림 문자를 보내는 기능입니다. 이 패키지는 무료로 제공되며 고려되지 않으므로 7과 같지 않습니다. 따라서 제거해야 합니다.

이렇게 많은 양의 데이터를 전체 테이블 순회하는 경우 우선 이 전체 테이블 검색 방법은 바람직하지 않습니다. 기본 키 ID 분할 형식으로 쿼리하는 것을 고려할 수 있습니다. 처음에는 > 0의 레코드 200개, 최대 ID를 기록한 다음 > 현재 최대 ID의 200개 레코드를 쿼리하는 식입니다

이 ID 세분화 시나리오에서는 packageId를 쿼리 조건에 안전하게 넣을 수 있습니다. 왜냐하면 기본 키 ID로 가야 하기 때문입니다. 따라서 mysql에서 필터링하는 최대 데이터 수는 200개에 불과하므로 문제는 크지 않습니다(200 예시일 뿐이며 실제 상황과 서비스 압력에 따라 조절하실 수 있습니다)

추가적인 이점은 현재 작업의 진행 상황을 실시간으로 관찰할 수도 있다는 점입니다(200명의 사용자를 보낸 후 로그할 수 있으며, 중단되면 어디서부터 시작해야 할지 알 수도 있습니다)


==== 원래 답변은 다음과 같습니다 ===

귀하의 쿼리에는 페이징이 없으며 여기서는 데이터의 양이 실제로 매우 작다고 가정합니다. 그리고 페이징이 없기 때문에 필연적으로 전체 테이블 스캔이 발생하므로 SQL 중에 직접 수행하십시오.
게다가 단순히 값과 같지 않기 때문에 !=을 사용하는 것이 더 직관적입니다

쿼리에 많은 양의 데이터가 있거나 실제로 페이징이 있는 경우(여기에 데모 코드가 아직 작성되지 않은 경우) 데이터를 쿼리하는 데 도움이 되는 다른 인덱스 쿼리 조건이 있는지 고려해야 합니다. 그렇지 않은 경우 이 packageId에 인덱스를 추가할지 여부를 고려해야 합니다(packageId의 분포가 이 테이블에 충분히 분산되어 있는 경우)

<code class="sql">select * from userPackage where packageId<>7</code>

직접 사용하기

첫 번째가 더 빠릅니다.
Mysql 쿼리 속도는 순회 속도보다 훨씬 빠릅니다. 순회할 때 반복 횟수가 적을수록 좋습니다.

첫 번째 속도여야 합니다. 모든 데이터를 꺼내지는 마세요. . . mysql은 참을 수 없어

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.