Общий вопрос оптимизации модели SQL (MySql) - PullRequest
0 голосов
/ 11 июня 2009

Мне нужно знать, есть ли лучший способ оптимизировать такую ​​модель БД:

Вот мои столы:

[category]
idCategory
name

[postCategory] (a post can be in more than 1 category)
idCategory
idPost

[post]
idPost
post

[comment]
idComment
idPost
inputDate
comment

Мне нужно будет отобразить все сообщения из определенной категории за определенный промежуток времени (время из «комментариев»). Диапазон времени является фиксированным (1 день, 1 неделя, 1 месяц, 1 год). Вот с чем я пришел:

SELECT DISTINCT(post.idPost), post.post 
from post 
INNER JOIN comment ON post.idPost = comment.idPost 
INNER JOIN postCategory ON postCategory.idPost = post.idPost 
WHERE postCategory.idCategory = <myCategoryId> 
    AND comment.inputDate >= <today - time range>

Допустим, я хочу поддерживать 10 тыс. Сообщений и 500 тыс. Комментариев ... Есть ли способ оптимизировать это (кроме использования индексов)? Вы бы использовали сохраненный процесс, запрос с временными таблицами, добавили бы куда-нибудь «предварительно вычисленные» поля ...?

Большое спасибо! :)

1 Ответ

0 голосов
/ 11 июня 2009

Я бы вычислил вашу <today - time range> часть клиентской части, прежде чем даже подключиться к базе данных.

Кроме того, это будет зависеть от того, какие у вас есть индексы, какая нагрузка на ваш сервер (что он хранит в кэше в памяти) и объем данных в каждой таблице (сколько комментариев на типичный пост, сколько постов в категория и т. д.). Другими словами, вам необходимо профиль . Если все, что является спорным (это не так!), Приличным оптимизатор запросов должен быть в состоянии в значительной степени заботиться о любых вещах еще.

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

В общем, мне нравится выражать свои запросы так, чтобы, если соединения выполнялись по порядку, набор результатов сохранялся как можно меньшим как можно дольше. В этом случае это, скорее всего, означало бы перечисление соединения postCategory над соединением comments и перемещение условия "= <MyCategoryID>" вверх, чтобы оно стало частью выражения соединения.

...