В таблице есть еще много полей. Я привел только основные, по которым нужна выборка.
Это таблица статистики отправки рассылок.
Данный запрос нужен для того, чтобы автоматически отписывать пользователей, которым 3 последних рассылки отправилось с ошибкой.

А id последних рассылок всегда одинаковые для всех подписанных пользователей?
Если так, то, наверное, в 2 запроса самый эффективный метод. В первом только выбор трех последних, во втором запросе просто 4 сравнения на каждую строку. Чего-то более быстрого придумать не могу.

Но все равно подумайте про отдельную таблицу. Если бы id рассылок было в отдельной таблице, то они выбирались бы куда быстрее, чем через группировку. Кроме того, количество рассылок меньшее за количество писем в столько раз, сколько подписчиков, а если учесть, что таблица забита еще и старыми подписчиками, то вообще совсем не рационально из нее часто что-то выбирать.

Это сообщение отредактировал(а) Arantir - 22.5.2013, 19:28

Судя по тому, что было озвучено раньше - да.


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

При такой организации у нас будет фуллскан малого набора данных + индексный доступ к логам. Такое решение, мне кажестся - достаточно мастшабируемое, в отличии от исходного. Потеря производительности, как и ранее, будет происходить с повышением количества абонентов рассылки, но с течением времени при равном количестве абонентов - не должна б.

Добавлено @ 00:33

Фуллскан с динстинктом первого запроса это то, что заставляет сжиматься сфинктор Злохи  

Добавлено через 7 минут и 16 секунд

Мне кажется что либо Злоха поспешил с заключением того, что он не был понят, либо Злоха составил это заключение до того, как пост подлежал редакции   

Это сообщение отредактировал(а) Zloxa - 23.5.2013, 00:35

Да, в сравнении с этим посты из темы Времени не существует просто отдыхают =)


Потому и спросил, что пришел к такому выводу на основе имеющихся данных.

Я бы вообще предложил последние 3 этих id хранить в кеше в оперативной памяти самого приложения. При потребности их можно восстановить из таблицы, но зато не придется каждый раз ради этого заставлять БД искать самые большие id среди миллионов строк.

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

Ну просто как-то не оптимально все это выглядит. Всего-то надо знать последние 3 результата отправки каждого пользователя, а столько ресурсов тратится. Если 1000 пользователей и 5000 писем, то это 5 млн. строк. Если иметь таблицу только с количеством последних ошибок каждого пользователя, то это 1000 строк. Даже, если придется пару строчек в программе дописать, то 5000000 против 1000 — разница немалая. Кроме того, отписанные там же в таблице писем и остаются, а из таблицы с ошибками отписанных можно удалять и искать придется только среди активных пользователей, что еще больше уменьшает затраты по сравнению с выборкой из таблицы всех когда-либо совершенных отправок писем.

Это сообщение отредактировал(а) Arantir - 23.5.2013, 01:17