Вопрос знатокам Mysql

подожду...

если будет время ...

у меня все работает как нужно, просто ради общего образования.

и интересно мнение по поводу 1 тяжелый запрос и реализация на пхп, или много простых запросов, но тоже не без участия пхп.

спасибо всем отвечающим

Видимо, как-то так:

SELECT r.pm_id AS pm_id, t.user1_id AS user1_id, t.user2_id AS user2_id, t.pm_user2_new AS pm_user2_new FROM ( SELECT Max(pm_id) AS pm_id FROM test GROUP BY user1_id ) r INNER JOIN test t USING(pm_id)

Для начала: получаете не первую запись, а случайную. Случайная, как правило, оказывается первой попавшейся, т.е. первой. Если сделать (допустим) alter table order by id desc то случайная, как правило, начнет оказываться последней при группировке. Это кстати можно назвать 0 вариантом, но он ненадежный, ибо "как правило" может и не сработать.

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

Тогда все же немного абстрактно (таблиц Ваших у нас нет для теста, ну и нужные данные приджоинить уже сможете сами).

1 вариант.

select a.*

from pm as a left join pm as b 

on (a.user1_id=b.user_1_id && a.user2_id=b.user2_id) and a.pm_id<b.pm_id

where b.pm_id is null group by a.pm_id

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

2 вариант

select * from messages where pm_id in (

 select max(pm_id) from pm group by user1_id, user2_id

)

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

3 вариант

Он не вполне решение Вашей постановки задачи, но как ни странно, он наиболее умное решение вопроса с точки зрения нагрузки. Добавьте еще одно поле - последнее непрочтенное сообщение. Выставляйте его при прочтении сообщений юзером, это будет один маленький редкий запрос, который сэкономит Вам в будущем кучу нервов и времени.

спасибо всем за ответы

немного руки не доходили до темы, за это прошу прощение.

ну апдейт лишний получается...

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

хотел бы уточнить, на что влияет кол-во запросов при довольно таки посещаемом сайте?

все остальные варианты потестиру. всем еще раз спасибо.