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

Ну я попытался при первом запросе кидать коды позиций прайса и ключ сессии в отдельную таблицу, а потом пользоваться ей для перехода по страницам. Это очень долго. Чересчур долго.

СУБД MySQL 5.x, Apache 2.x, Perl 5.8, Linux Ubuntu, машина, в технике не рабираюсь, но быстро тянет текущий веб-сайт со сложными отборами в больших массивах, параллельным обновлением больших массивов информации с СУБД MSSQL и т.д. На машину пенять нечего.

Средний отбор вмещает в себя от 10000 позиций.

Что можете предложить для решения проблемы перехода по хаотично отсортированной информации?

Хотя, путём INSERT INTO ...(...) SELECT FROM .... получается быстрее, всё равно мне такой способ не нравится.