Блокировка БД и оптимизация запросов

Для начала покажите

show create table bb_sessions;

select count(*) from bb_sessions;

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

Делайте UPDATE не при каждом дёргании страницы, а только когда сессия скоро "протухнет". Или раз в пять-десять минут. То есть UPDATE станут в основном SELECT-ами, а последние работают значительно быстрее. И, мне кажется, в этом UPDATE достаточно обновлять лишь session_time = 1232545451.

Если таблица таблица в памяти enigine=memory, то это все ерунда. по крайней мере в vbulletin никто не спешит убирать подобный же запрос и он никогда не тормозит.

В memory своя проблема - запись идёт значительно дольше, чем чтение. Хотя да, лучше эту таблицу держать в памяти.

Слава Шевцов, ну с чего бы ей тормозить?

обычные запросы используют такие таблицы неявно в качестве временного хранилища и ничего никто не замечает.

Фиг его знает. Тесты показывают, что скорость чтения записи из хешевых таблиц раз в пять выше, чем обновление записи в них же. Хотя в чём там дело - сам понять не могу.

думаю, дело то как раз в том что таблица адресуется хешами. Для поиска данных в ней используется один шаг, грубо говоря, а для вставки - от 1 до бесконечности в зависимости от размера таблицы и используемой хеш-функции. Но это должна быть жирная таблица, навскидку больше 50 тыщ записей. Временные таблицы в пуле при селектах довольно мелкие как правило. Редко кто-то передает в скрипт хотя бы тысячу записей. А апдейт еще более затратный в связи с необходимостью пересчета таблицы адресации. Если сессии давно не чистились, то там наверное ОЧЕНЬ большая таблица поэтому и тормоза на апдейте.

Поскольку в данном случае сам запрос оптимизировать уже некуда (кол-во записываемых полей имеет минимальное значение, в отличие от кол-ва полей сверки), остается минимизировать число его вызовов. Возможно, действительно стоит задумываться об обновлении сессии не на каждом переходе, а за N времени до её окончания. и ессно добавить один запрос select чтобы найти таковые, и в случае ненадобности, отсечь вызов апдейта.

Но вообще меня удивляет какие то претензии хостера к phpbb2. Сколько их запустил-поставил, ни разу не было жалоб.

Слава Шевцов, а тест у вас сильно параллельный был? дело в том, что там блокировка глобальная на всю таблицу. попробуйте на один из тысячи запросов записывать show profile и, возможно, увидите в чем дело. Есть еще патчи где slow_log записывает миллисекунды и , что очень важно в таких случаях, время, которое запрос ожидал блокировки.