Отримайте додаткові підрахунки зведеного значення в об'єднаній таблиці


10

У базі даних MySQL 5.7.22 у мене дві таблиці: postsі reasons. Кожен рядок повідомлень містить і належить до багатьох рядків причин. Кожна причина має вагу, пов'язану з нею, і тому кожен пост має повну сукупну вагу, пов'язану з нею.

На кожен приріст у 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)
);

Поки я намагався скинути ідентифікатор публікації та загальну вагу в подання, а потім приєднав цей погляд до себе, щоб отримати сукупний підрахунок:

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 хвилин без закінчення, чого я не можу зробити у виробництві.

Чи є більш ефективний спосіб зробити це?

Якщо ви зацікавлені в тестуванні всього набору даних, його можна завантажити тут . Файл становить близько 60 Мб, він розширюється приблизно до 250 Мб. З іншого боку , є 12000 рядків по суті GitHub тут .

Відповіді:


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 процесор при 3,20 ГГц і 8 Гб оперативної пам’яті.

uname -a Linux dustbite 4.16.6-302.fc28.x86_64 # 1 SMP ср 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

Ах, вибачте. Я перепишу запит
Леннарт

Це отримало мені решту шляху, хоча, так дякую! Просто потрібно було вибрати з існуючого post_weightsпредставлення, яке я вже створив замість reasons.
ArtOfCode

@ArtOfCode, чи правильно я його переглянув? BTW, дякую за відмінне запитання. Чіткі, стислі та з вибіркою даних партії. Браво
Леннарт

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 скаржиться, ERROR 1055 (42000): 'd.reason_weight' isn't in GROUP BYякщо він ONLY_FULL_GROUP_BYзнаходиться в @@ sql_mode. Відключивши його, я помітив, що ваш запит повільніше, ніж мій перший раз, коли він запускається (~ 11 сек). Після кешування даних це відбувається швидше (~ 1 сек). Мій запит виконується приблизно за 4 секунди кожного разу.
Леннарт

1
@Lennart: Це тому, що це не власне запит. Я виправив це у скрипці, але забув оновити відповідь. Оновлення зараз, дякую за голову.
Андрій М

@Lennart: Щодо продуктивності, у мене може виникнути помилкове уявлення про цей тип запиту. Я подумав, що це має працювати ефективно, оскільки розрахунки будуть завершені за один прохід над таблицею. Можливо, це не обов’язково так, як це стосується похідних таблиць, зокрема тих, що використовують агрегацію. Боюся, у мене немає ні належної установки MySQL, ні достатнього досвіду для глибшого аналізу.
Андрій М

@Andriy_M, здається, це помилка у моїй версії MariaDB. Це не любить, GROUP BY FLOOR(reason_weight / 10)але приймає GROUP BY reason_weight. Що стосується продуктивності, я, звичайно, не є експертом, навіть коли мова йде про MySQL, це було лише спостереженням за моєю дурною машиною. Оскільки я запустив свій запит спочатку, всі дані повинні були вже кешуватися, тому я не знаю, чому це було повільніше, коли перший раз він запускався.
Леннарт
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.