Например так?

Ну смотря как посмотреть Обычно быстро обрабатывается подсчет без условия WHERE, потому что он берется..откуда-то из данных статистики самой таблицы. А когда ты ставишь WHERE, то строчки в прямом смысле считаются. И тут уже грамотность индексированния таблицы влияет на скорость выборки. Нет индексов - получишь нагрузку, есть - замечательно, разгрузишь БД

Подтверждаю: разница во времени запроса с индесками и без них может составлять десятки, и иногда сотни раз. Самолично походил немного по этим граблям

Всмысле без WHERE? Может удивлю, но вот так:

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

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

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

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

Ну хоть убейте Я понимаю, что кэшировать запросы можно и НУЖНО, но не могу без содрогания видеть как кэшируют запрос по количеству непрочтенных сообщений (и т.п.). как представить сколько таких файлов будет валяться (ну или просто памяти - если говорить о кэшировании eaccelerator, apc и т.п.) - а в сумме они огого будут да еще наверно по такому файлу для... групп скажем (если соц сеть взять к примеру). это же пруд пруди файлов...

Ну хоть убейте... Не пойму такого подхода

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

я щас чуть слезу не пустил от эмоций (преувеличиваю, конечно но не стебусь)

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

Эт хорошо "В споре рождается истина" Значит истина - гриб

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

Скорее "подсадит", а не "пересадит"

А мне придёЦЦа, наверное, MySQL подучить немного. Чтобы хоть сравнивать можно было эти две БД.

Э, нет, батенька! ПотрудиЦЦа придёЦЦа Там, в Постгре, еще очень много-много интересного.

Что правда то правда. сижу себе пишу на mysql. ну слышал, что есть такой postgre, который тоже очень популярен в среде php. а тут еще узнаю, что там distinct круче, чем в mysql (может еще много чего круче, кто знает). вот теперь и правда... "пересадит"

ну и спасибо ему, что вот появляется желание в нем покопаться. без желания и не сядешь, пока нужда не прижмет. а так - когда она прижмет, уже готов будешь

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

* сбегал за документацией по postgre в гугл *
ну вот я уже знаю, что там есть подготовленные запросы и процедуры - значит изучение оправдывает себя