하위 쿼리와 하위 쿼리를 결합하여 중첩 된 개체를 계산합니다.

내 모델에 사람과 주소라는 두 개의 테이블이 있다고 가정 해 봅니다. 한 사람은 O, 하나 이상의 주소를 가질 수 있습니다. 모든 사람을 나열하고 각각 주소가있는 주소를 포함하는 쿼리를 실행하려고합니다.하위 쿼리와 하위 쿼리를 결합하여 중첩 된 개체를 계산합니다.

SELECT 
    persons.*, 
    count(addresses.id) AS number_of_addresses 
FROM `persons` 
    LEFT JOIN addresses ON persons.id = addresses.person_id 
GROUP BY persons.id

및

SELECT 
    persons.*, 
    (SELECT COUNT(*) 
    FROM addresses 
    WHERE addresses.person_id = persons.id) AS number_of_addresses 
FROM `persons`

그리고 한 성능의 기간에 다른 것보다 더 나은 경우 궁금 해서요 : 여기가 달성해야하는 2 개 쿼리입니다.

출처

2016-07-04 TrexXx

이'cube_models' 테이블은 무엇이며 왜 두 번째 쿼리에만 나타 납니까? 두 번째 쿼리는 일반적으로 조인을 사용하는 비슷한 쿼리보다 느리게 실행되는 상관 된 하위 쿼리를 사용합니다. –

나는 첫번째 것이 더 빠를 것이라고 믿는다. 그러나 그들은 매우 유사하다. 두 가지 모두에서 실행 계획을 실행하고 차이점을 확인하십시오. 나는 그것을하는 더 좋은 방법이 있는지 의심 스럽다. – sagi

큐브 모델을 수정했는데, 불량 복사/붙여 넣기 – TrexXx

성능 특성을 결정하는 방법은 실제로 쿼리를 실행하고 어떤 것이 더 좋은지 확인하는 것입니다.

색인이없는 경우 첫 번째 색인이 더 좋습니다. addresses(person_id)에 대한 색인이있는 경우 두 번째 색인이 더 좋습니다.

이유가 조금 복잡합니다. 기본적인 이유는 group by (MySQL의 경우)이 정렬을 사용한다는 것입니다. 그리고, 종류는 O (n * log (n)) 복잡합니다. 따라서 정렬 작업을 수행하는 데 걸리는 시간이 데이터보다 빠릅니다 (그다지 빠르지 않지만 조금 빠름). 결과적으로 각 개인에 대한 많은 수의 집계가 모든 데이터에 대한 개인의 집계보다 빠릅니다.

그건 개념적입니다. 실제로, MySQL은 상관 된 서브 쿼리를 위해 인덱스를 사용하기 때문에 인덱스를 사용하지 않는 전체 group by보다 더 빠르다.

출처

2016-07-04 15:00:08

저는 첫 번째 쿼리가 최적이라고 생각하며 테이블 구조를 변경하여 더 많은 최적화를 제공 할 수 있습니다. 예를 들어 person_id와 address_id 필드를 모두 정의하면 (순서가 중요 함) 주소 테이블의 기본 키로 더 빨리 결합 할 수 있습니다.

mysql 테이블 저장소 구조는 인덱스 된 구성 테이블 (클러스터 된 인덱스)이므로 기본 키 인덱스는 조인 작업에서 일반 인덱스보다 매우 빠릅니다.

출처

2016-07-04 15:07:35

'persons.id','addresses.id' 및'addresses.person_id' 모두 인덱스가 – TrexXx

입니다. @TrexXx, mysql 테이블 스토리지 구조는 인덱스 된 구성 테이블 (클러스터 됨)이므로 기본 테이블 키 인덱스는 조인 작업에서 일반 인덱스보다 매우 빠릅니다. –

하위 쿼리와 하위 쿼리를 결합하여 중첩 된 개체를 계산합니다.

답변

관련 문제