В веб-приложении авторизация и идентификация пользователей устроена таким образом, что все сессии хранятся в таблице:



На каждой странице выполняется запрос:


и в зависимости от отваета 

или


Также каждые 2 минуты запускается очистка от записей, где `time` меньше на 3600 от текущего.

Как можно оптимизировать запросы и таблицу? Правильно ли выбран ключ? Спасибо.

заменить все три запроса на один


Добавлено через 57 секунд

недостаточно данных для осмысленного ответа.

Спасибо!

А какие данные надо предоставить для осмысленного ответа?

Добавлено через 1 минуту и 10 секунд
Еще забыл спросить, правильно ли выбран тип таблицы ENGINE=MEMORY? Данные временные, при перезагрузке сервера восстанавливать не имеет смысла, при сбое тоже.

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


Зависит от прогнозируемого максимального объёма данных в таблице.

На пару IP-SESID в таблице будет только одна запись, если Вы об этом.
Но возможно существование записей с одним IP, но разными SESID


Явное преобладание



Нет. Все поступающие данные уже подготовлены, все исходящие обрабатываются непосредственно программой.



Максимальный прогнозируемый 500 записей

Это сообщение отредактировал(а) Smorodin - 3.12.2010, 11:35

В таком случае ключ выбран скорее правильно, чем нет. Хотя от тебя требуется подтвердить допустимость ОДНОВРЕМЕННОГО существования двух сессий с одним номером, но с разных ИПов. В зависимости от задачи может потребоваться считать, что идентификатор сессии - это уникально, а ИП проверять на неизменность, и при изменении сбрасывать сессию. 
Да! не забудь - по умолчанию MEMORY-движок использует hash-индексы. Если тебе нужен строго B-tree, то укажи это явно в структуре таблицы.


А размер записи - около килобайта. Да, MEMORY вполне нормальный выбор.

Пятьсот записей... по килобайту.....не сохраняемые....

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

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

Представил. Не понял. Сериализовать доступ к коллекции приложения должно бы быть не сложно.

Это допустимо, извините, что сразу об этом не подумал.

Всем спасибо за обсуждение!
Но ассоциативный массив на стороне приложения - не самый лучший шаг. Если бы SESID была уникальным идентификатором, можно было бы назначить ключем элемента массива. Искать по элементам с ключем SESID, где IP=искомому? Массив получится очень динамичный, с постоянной записью. Если хранить в файле - рано или поздно придется задуматься о блокировке на запись, очереди. Недоработку по структуре таблицы исправить гораздо проще, чем изменять структуру или логику определенной части приложения. Во всяком случа, для меня.
Если случится такое, что число записей выростет до 5000? 

А что если таблицу переложить на eaccelerator или memcashe? Как считаете?