조인 된 테이블에서 집계 된 값의 증분 수 가져 오기


10

나는 MySQL은 5.7.22 데이터베이스에 두 개의 테이블을 가지고 postsreasons. 각 게시물 행에는 여러 이유 행이 있고 그에 속합니다. 각 이유에는 관련 가중치가 있으므로 각 게시물에는 전체 집계 가중치가 있습니다.

10 점씩 증가 할 때마다 (즉, 0, 10, 20, 30 등) 총 가중치가 해당 증분 이하인 게시물 수를 얻고 싶습니다. 그 결과가 다음과 같이 보일 것으로 기대합니다.

 weight | post_count
--------+------------
      0 | 0
     10 | 5
     20 | 12
     30 | 18
    ... | ...
    280 | 20918
    290 | 21102
    ... | ...
   1250 | 118005
   1260 | 118039
   1270 | 118040

총 가중치는 거의 정규적으로 분포되어 있으며 매우 낮은 값과 매우 높은 값 (현재 최대 1277)이지만 대부분 중간에 있습니다. 에 120,000 개 미만의 행이 posts있고 약 120 개의 행 이 reasons있습니다. 각 게시물에는 평균 5-6 개의 이유가 있습니다.

표의 관련 부분은 다음과 같습니다.

CREATE TABLE `posts` (
  id BIGINT PRIMARY KEY
);

CREATE TABLE `reasons` (
  id BIGINT PRIMARY KEY,
  weight INT(11) NOT NULL
);

CREATE TABLE `posts_reasons` (
  post_id BIGINT NOT NULL,
  reason_id BIGINT NOT NULL,
  CONSTRAINT fk_posts_reasons_posts (post_id) REFERENCES posts(id),
  CONSTRAINT fk_posts_reasons_reasons (reason_id) REFERENCES reasons(id)
);

지금까지 게시물 ID와 가중치를 뷰에 드롭 한 다음 해당 뷰를 자체에 결합하여 집계 수를 얻었습니다.

CREATE VIEW `post_weights` AS (
    SELECT 
        posts.id,
        SUM(reasons.weight) AS reason_weight
    FROM posts
    INNER JOIN posts_reasons ON posts.id = posts_reasons.post_id
    INNER JOIN reasons ON posts_reasons.reason_id = reasons.id
    GROUP BY posts.id
);

SELECT
    FLOOR(p1.reason_weight / 10) AS weight,
    COUNT(DISTINCT p2.id) AS cumulative
FROM post_weights AS p1
INNER JOIN post_weights AS p2 ON FLOOR(p2.reason_weight / 10) <= FLOOR(p1.reason_weight / 10)
GROUP BY FLOOR(p1.reason_weight / 10)
ORDER BY FLOOR(p1.reason_weight / 10) ASC;

그러나 그것은 사용할 수 없을 정도로 느리다. 나는 종료하지 않고 15 분 동안 작동시켰다. 나는 생산에서 할 수 없었다.

더 효율적인 방법이 있습니까?

전체 데이터 세트 테스트에 관심이있는 경우 여기 에서 다운로드 할 수 있습니다 . 파일 크기는 약 60MB이며 약 250MB로 확장됩니다. 또는 GitHub 요지에 12,000 개의 행이 있습니다 .

답변:


8

JOIN 조건에서 함수 또는 표현식을 사용하는 것은 일반적으로 나쁜 생각입니다. 저는 일반적으로 일부 옵티마이 저가 상당히 잘 처리하고 인덱스를 활용할 수 있기 때문에 말합니다. 가중치 테이블을 만드는 것이 좋습니다. 다음과 같은 것 :

CREATE TABLE weights
( weight int not null primary key 
);

INSERT INTO weights (weight) VALUES (0),(10),(20),...(1270);

에 대한 색인이 있는지 확인하십시오 posts_reasons.

CREATE UNIQUE INDEX ... ON posts_reasons (reason_id, post_id);

다음과 같은 쿼리 :

SELECT w.weight
     , COUNT(1) as post_count
FROM weights w
JOIN ( SELECT pr.post_id, SUM(r.weight) as sum_weight     
       FROM reasons r
       JOIN posts_reasons pr
             ON r.id = pr.reason_id
       GROUP BY pr.post_id
     ) as x
    ON w.weight > x.sum_weight
GROUP BY w.weight;

집에있는 기계는 아마도 5-6 세이며, 3.20GHz에서 Intel (R) Core i5-3470 CPU와 8Gb의 램을 가지고 있습니다.

uname -a Linux dustbite 4.16.6-302.fc28.x86_64 # 1 SMP 수 5 월 2 일 00:07:06 UTC 2018 x86_64 x86_64 x86_64 GNU / Linux

나는 다음에 대해 테스트했다.

https://drive.google.com/open?id=1q3HZXW_qIZ01gU-Krms7qMJW3GCsOUP5

MariaDB [test3]> select @@version;
+-----------------+
| @@version       |
+-----------------+
| 10.2.14-MariaDB |
+-----------------+
1 row in set (0.00 sec)


SELECT w.weight
     , COUNT(1) as post_count
FROM weights w
JOIN ( SELECT pr.post_id, SUM(r.weight) as sum_weight     
       FROM reasons r
       JOIN posts_reasons pr
             ON r.id = pr.reason_id
       GROUP BY pr.post_id
     ) as x
    ON w.weight > x.sum_weight
GROUP BY w.weight;

+--------+------------+
| weight | post_count |
+--------+------------+
|      0 |          1 |
|     10 |       2591 |
|     20 |       4264 |
|     30 |       4386 |
|     40 |       5415 |
|     50 |       7499 |
[...]   
|   1270 |     119283 |
|   1320 |     119286 |
|   1330 |     119286 |
[...]
|   2590 |     119286 |
+--------+------------+
256 rows in set (9.89 sec)

성능이 중요하고 다른 방법으로 도움이되지 않는 경우 다음에 대한 요약 테이블을 작성할 수 있습니다.

SELECT pr.post_id, SUM(r.weight) as sum_weight     
FROM reasons r
JOIN posts_reasons pr
    ON r.id = pr.reason_id
GROUP BY pr.post_id

트리거를 통해이 테이블을 유지할 수 있습니다

각 중량에 대해 특정 양의 작업이 수행되어야하므로이 표를 제한하는 것이 유리할 수 있습니다.

    ON w.weight > x.sum_weight 
WHERE w.weight <= (select MAX(sum_weights) 
                   from (SELECT SUM(weight) as sum_weights 
                   FROM reasons r        
                   JOIN posts_reasons pr
                       ON r.id = pr.reason_id 
                   GROUP BY pr.post_id) a
                  ) 
GROUP BY w.weight

가중치 테이블 (최대 2590)에 불필요한 행이 많으므로 위의 제한으로 실행 시간이 9 초에서 4 초로 줄었습니다.


설명 : 이것은 무게가 더 작은 계산 이유 인 것 같습니다 w.weight-맞습니까? lte 의 가중치 (관련 이유 행의 가중치 합계)로 게시물을 계산하려고합니다 w.weight.
ArtOfCode

아 죄송합니다 나는 쿼리를 다시 쓸 것이다
Lennart

이것은 나에게 나머지 길을 얻었으므로 감사합니다! post_weights내가 대신 이미 만든 기존 보기 에서 선택해야했습니다 reasons.
ArtOfCode

@ArtOfCode, 수정 된 쿼리에 맞습니까? BTW, 훌륭한 질문에 감사드립니다. 명확하고 간결하며 많은 샘플 데이터가 있습니다. 브라보
Lennart

7

MySQL에서는 변수를 열의 값에서 계산하고 계산 된 새 열의 표현식에 사용하는 쿼리에 사용할 수 있습니다. 이 경우 변수를 사용하면 효율적인 쿼리가 생성됩니다.

SELECT
  weight,
  @cumulative := @cumulative + post_count AS post_count
FROM
  (SELECT @cumulative := 0) AS x,
  (
    SELECT
      FLOOR(reason_weight / 10) * 10 AS weight,
      COUNT(*)                       AS post_count
    FROM
      (
        SELECT 
          p.id,
          SUM(r.weight) AS reason_weight
        FROM
          posts AS p
          INNER JOIN posts_reasons AS pr ON p.id = pr.post_id
          INNER JOIN reasons AS r ON pr.reason_id = r.id
        GROUP BY
          p.id
      ) AS d
    GROUP BY
      FLOOR(reason_weight / 10)
    ORDER BY
      FLOOR(reason_weight / 10) ASC
  ) AS derived
;

d파생 테이블은 실제로입니다 post_weights볼 수 있습니다. 따라서 뷰를 유지하려는 경우 파생 테이블 대신 뷰를 사용할 수 있습니다.

SELECT
  weight,
  @cumulative := @cumulative + post_count AS post_count
FROM
  (SELECT @cumulative := 0),
  (
    SELECT
      FLOOR(reason_weight / 10) * 10 AS weight,
      COUNT(*)                       AS post_count
    FROM
      post_weights
    GROUP BY
      FLOOR(reason_weight / 10)
    ORDER BY
      FLOOR(reason_weight / 10) ASC
  ) AS derived
;

축소 된 설정 버전의 간결한 버전을 사용하는이 솔루션의 데모는 SQL Fiddle에서 찾아서 재생할 수 있습니다 .


전체 데이터 세트로 쿼리를 시도했습니다. 왜 (질문이 나에게 잘 보이는지) 확실하지 않지만 MariaDB 는 @@ sql_mode 에 ERROR 1055 (42000): 'd.reason_weight' isn't in GROUP BY있는지 불평 ONLY_FULL_GROUP_BY합니다. 이 기능을 사용 중지하면 쿼리가 처음 실행될 때 (~ 11 초)보다 느립니다. 데이터가 캐시되면 더 빠릅니다 (~ 1 초). 내 쿼리는 매번 약 4 초 안에 실행됩니다.
Lennart

1
@Lennart : 실제 쿼리가 아니기 때문입니다. 바이올린으로 수정했지만 답변을 업데이트하는 것을 잊었습니다. 지금 업데이트 해 주셔서 감사합니다.
Andriy M

@Lennart : 성능에 관해서는이 유형의 쿼리에 대해 오해가있을 수 있습니다. 계산이 테이블을 한 번에 완료되므로 효율적으로 작동해야한다고 생각했습니다. 아마도 파생 테이블, 특히 집계를 사용하는 테이블의 경우는 아닙니다. 그래도 적절한 MySQL 설치 나 심층 분석을위한 충분한 전문 지식이없는 것이 걱정됩니다.
Andriy M

@ Andriy_M, MariaDB 버전의 버그 인 것 같습니다. 그것은 좋아하지 GROUP BY FLOOR(reason_weight / 10)않지만 받아들 GROUP BY reason_weight입니다. 성능에 관해서는 MySQL에 관해서는 확실히 전문가가 아닙니다. 크 래피 머신에서 관찰 한 것입니다. 쿼리를 먼저 실행했기 때문에 모든 데이터가 이미 캐시되어 있어야했기 때문에 처음 실행했을 때 왜 느려졌는지 알 수 없습니다.
Lennart
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.