MySQL просмотров производительности против дополнительного столбца - PullRequest
Новая
       21

MySQL просмотров производительности против дополнительного столбца

0 голосов
/ 18 февраля 2012

Мой вопрос касается выбора лучшего метода для выполнения работы.Я представлю цель и мои различные решения.

У меня есть список предметов и список категорий.каждая может принадлежать к нескольким категориям. 

items          (id, name, ...other fields...)
categories     (id, name, ...... )
category_items (category_id, item_id)

список предметов очень большой и обновляется каждые 10 минут (с использованием cron).список категорий фиксирован.

на моей странице, я показываю большой список элементов, и у меня есть фильтры категорий.Вся фильтрация выполняется на клиентском JavaScript.Причина в том, что количество доступных в настоящее время элементов ограничено + - 1000, поэтому все данные (элементы + категории) будут загружаться вместе.

эта страница будет просматриваться много раз, поэтому производительностьпроблема здесь.У меня есть несколько идей, обе приведут к хорошей производительности.во всех них будет отправлен полный список категорий.однако элементы ...

  1. , выполняющие одиночный выбор, используя join и group_concat.что-то вроде этого:

    SELECT i. *, GROUP_CONCAT (ci. category_id SEPARATOR ",") AS category_list FROM items AS I LEFT JOIN category_items AS ci ON (ci. item_id = i. id) WHERE ... GROUP BY i. id ORDER BY ...

  2. создание представления с указанным выше

  3. сохранение результата GROUP_CONCAT в качестве дополнительного столбца.это будет обновляться только каждые несколько минут в cron.

индексация выполняется правильно, поэтому все методы будут работать относительно быстро.объединение - сложная операция, поэтому мой вопрос о (2), (3):

обновляется ли представление только для каждого CRUD или оно рассчитывается для каждого выбора?если он обновляется только в CRUD, он должен быть примерно таким же, как при хранении столбца.

Помните, что таблица элементов будет расти и будут выбраны только последние строки.

Ответы [ 2 ]

1 голос
/ 18 февраля 2012

Создание представления - это просто сохранение запроса, (2) все равно запустит запрос и объединение. (3) конечно сэкономит время за счет места.

Ответ, следовательно, является вопросом: вы и ваше приложение значение времени или пространства?

Кроме того, вместо использования cron для обновления поля кэша (вашего GROUP_CONCAT) вы можете использовать триггер для таблицы category_items;

1 голос
/ 18 февраля 2012

Решение 4. Иметь таблицу типа MEMORY, которая будет обновлена ​​результатами вашего запроса из решения 1 тем же скриптом cron, который обновляет таблицу items.

Кроме этого: 1. и 2. эквивалентны. Представления MySQL не материализованы, поэтому запрос представления фактически запустит SELECT из пункта 1.

...