производительность большой INSERT с данными из огромного выбора

Question

Мы генерируем некоторые перекрестные данные для магазина. Мы хотим отображать такие вещи, как «клиенты, которые смотрели этот продукт, также смотрели эти продукты». Чтобы сгенерировать эти данные, мы выполняем этот запрос на ежедневной основе из данных просматриваемого продукта на основе сеанса.

            INSERT INTO
                product_viewed_together
            (
                product,
                product_associate,
                viewed
            )
            SELECT
                v.product,
                v2.product,
                COUNT(*)
            FROM
                product_view v
            INNER JOIN
                product_view v2
            ON
                v2.session = v.session
                AND v2.product != v.product
                AND DATE_ADD(v2.created, INTERVAL %d DAY) > NOW()
            WHERE
                DATE_ADD(v.created, INTERVAL %d DAY) > NOW()
            GROUP BY
                v.product,
                v2.product;

Таблица product_view присоединяется к себе. Поскольку эта таблица довольно большая (около 26 миллионов строк), результат еще больше. Запрос выдает огромное количество производительности и времени.

Я не использую, мы выбрали макет, подходящий для проблемы. Есть ли лучший способ хранить и генерировать эти данные?

Answer 1

Сделать дату проверки sargable :

DATE_ADD(v.created, INTERVAL %d DAY) > NOW()

->

v.created > NOW - INTERVAL %d DAY

Является ли product_view a VIEW? Или TABLE? Если таблица , укажите два «покрывающих» индекса:

INDEX(created, session, product)  -- (for v)
INDEX(session, created, product)  -- (for v2)

Возможно, все полученные вами значения равны даже ? Эту ошибку можно исправить примерно тремя способами, каждый удвоит скорость. Я думаю, что оптимальным является изменение одной строки в ON на

DATE_ADD(v2.created, INTERVAL %d DAY) > NOW()

->

v2.created > v.created

Я думаю, что это удвоит скорость .

Однако количество может быть не совсем правильным, если у вас может быть два разных продукта с одинаковым created.

Еще одна проблема : вы получите

prod  assoc  CT
123   234    43
234   123    76  -- same pair, opposite order

Мой пересмотренный тест говорит, что 234 предшествовал 123 чаще, чем другой путь.

Попробуйте эти вещи. Но если вам все еще нужно больше; У меня есть другая, более агрессивная мысль.