結合されたテーブルの集計値の増分カウントを取得する


10

私は、MySQL 5.7.22、データベース内の2つのテーブルを持っている: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年前のもので、Intel(R)Core(TM)i5-3470 CPU @ 3.20GHzと8GbのRAMを搭載しています。

uname -a Linux dustbite 4.16.6-302.fc28.x86_64#1 SMP Wed May 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 2018年

@ArtOfCode、私は修正されたクエリのためにそれを正しく理解しましたか?ところで、素晴らしい質問をありがとう。明確で簡潔な、多数のサンプルデータを使用します。ブラボー
レナート2018年

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:パフォーマンスに関しては、このタイプのクエリについて誤解しているかもしれません。計算はテーブルの1回のパスで完了するため、効率的に機能するはずだと思いました。おそらく、派生テーブル、特に集計を使用するテーブルでは必ずしもそうではありません。ただし、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.