Форум пользователей MySQL

yuriy написал:

Привет, всем!!!
Подскажите, плиз.
Есть большая табл. (порядка 10 мил. записей).

мы помним

yuriy написал:

Пользователи обращаются к ней с запросами на выборку данных.
Данные возвращаются в кол-ве 1000-5000 записей. Соответственно для этих целей организован пейджер, чтобы можно было удобно просматривать весь результат.

поясните, что значит возвращаются 1000-5000 записей? прям все отдаются скрипту? Обычно пагинаторы работают с использованием LIMIT x,y где x - текущее смещение передаваемое через url, а y - количество записей на страницу. При этом используется либо связка SQL_CALC_FOUND_ROWS + FOUND_ROWS() либо COUNT() + SELECT для подсчета общего количества найденных (но не возвращенных разумеется) строк. А у вас как? Покажите запросы?

yuriy написал:

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

покажите нам что-то из этого, лучше всё:
1. структуру таблиц,
2. подтормаживающие запросы
3. результат их EXPLAIN

если верить вам, в том плане что вы реально вынимаете 5000 записей из базы, а потом с помощью скрипта-пагинатора отсеиваете например 25 для показа - то тормоза неизбежны и конечно временные таблицы вам не помогут. Кстати один раз я встречал такой "удивительный" подход.

yuriy написал:

А учитывая что таких пользователей будет сотня а то и больше, можно как-то организовать, чтобы выборка для каждого из пользователей сохранялась у временной промежуточной таблице чтобы снизить нагрузку на одну общую таблицу?
Подумывал создать временных TEMPORARY таблицы, но они существуют до конца подключения и сразу уничтожаются! Может быть есть другой подход для решения данной задачи!
Спасибо за любой совет!

Организовать такое можно.
1. выдаете пользователю в куку уникальный ключ
2. именем этого ключа именуете некую таблицу A типа CREATE TABLE IF NOT EXISTS usersearch_{ключ} LIKE {ваша большая таблица}
3. Делаете таблицу B с двумя колонками в которой храните пару имя_таблицы_usersearch_{ключ}/время последнего_обращения_к_ней
4. При первом поисковом запросе, то что нашли сохраняете в таблицу A:

и дальше работаете только с ней
5. При этом заносите в таблицу B соответствующую пару
6. Пока пользователь не меняет характеристики поиска, а только бегает по пагинатору (определяете на уровне приложения) работаете только с таблицей A, при каждом таком пролистывании обновляете пару в таблице B
7. как только что то в поиске поменялось, начинаете всё с пункта 4, не забыв табличку предварительно TRUNCATE (и апдейт B)
8. поднимаете кронтаб, если не уже, в нем пишете вызов специального чистильщика - маленький скрипт, который смотрит табличку B на предмет записей более старых чем N (ну допустим час) и либо чистит соответствующие таблицы, либо вовсе их удаляет

Вуаля, вы практически напишете свой кэширующий сервер :)

UPD. Думаю обновление таблички B будет очень удобно повесить на триггер а зачистку таблиц на mysql event sheduler - было бы здорово, если вы разберетесь и нам расскажете получилось ли

UPD2 В принципе можно пойти еще дальше.
Каждый поисковый запрос можно сериализовать зачистив от лишних, не влияющих на результат поиска символов (лишних пробелов например), затем получать от полученной строки некий ключ2, например с помощью md5() и на 2 шаге делать таблицы usersearch_ключ2 в которых хранить результаты поиска. Этот вариант интересен тем, что любой другой пользователь, который запросит тоже самое что первый - тоже будет работать с этой таблицей (их уже лучше не чистить, по крайней мере нечасто, идеально построить некую статистическую модель очистки, основанную на частотности попадания в такой результат (ну 1 раз в месяц такое ищут - грохнуть, а 300 раз в день - нет, например)). Т.е алгоритмы работы с такими таблицами будут немножко другими. Попробуйте, мне очень интересно что у вас из этого получится

Отредактированно Shopen (25.10.2012 01:20:26)