Стоимость выполнения левого соединения в MySQL против кэширования данных

поэтому у меня есть этот проект со следующими таблицами MySQL :

Таблица содержимого

+------------+------------+
| content_id | some infos |
+------------+------------+
|          1 | ...        |
|          2 | ...        |
+------------+------------+

Таблица заголовка

+----+----------+---------+------------+--------------+
| id |  title   | user_id | content_id | other things |
+----+----------+---------+------------+--------------+
|  1 | "blabla" |       1 |          1 | ...          |
|  2 | "blabla" |      59 |         25 | ...          |
+----+----------+---------+------------+--------------+

Чтобы быстро возобновить работу системы, несколько пользователей присваивают заголовки содержимому. Но каждый раз, когда я выбираю контент, мне нужно найти соответствующий заголовок (я беру наиболее последовательный пользователь witch опубликовал заголовок к этому контенту).

Итак, для этого я вижу 2 решения :

  • Я могу сделать выбор в таблице содержимого с левым соединением в таблице заголовка и моей пользовательской таблице с некоторыми MAX (nb_subscribers) …
  • Я могу сделать выбор только на содержимом , а затем использовать кэш-систему, такую как Redis, чтобы кэшировать заголовок в течение примерно 1 дня (в этом случае потребовался бы новый вызов MySQL, если заголовок не найден)

Основная проблема заключается в том, что это содержимое будет загружаться очень большое количество раз, и я хотел бы знать ваш adivise, если метод LEFT JOIN потребует много времени для обработки.

1 ответ

  1. Я не вижу ничего плохого в том, чтобы сделать LEFT JOINмежду contentи titleтаблицей, предполагая, что у последней есть индекс на content_idстолбце:

    SELECT c.*, t.*
    FROM content c
    LEFT JOIN title t
        ON c.content_id = t.content_id
    -- can also join to user table if needed