Всем огромное спасибо но мы совсем ушли от темы.
Человек говорил про

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

Да тут вы правы. При опять же больших объемах это вынужденный ход. Я упустил из виду эти примеры.

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

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

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

Это сообщение отредактировал(а) krundetz - 5.1.2009, 17:46

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

А теперь по теме. На счет 10 секундной задержки. Здается мне что такая задержка может быть в случае выборки всех записей (34 000) из таблицы одним запросом..

Добавлено через 3 минуты и 33 секунды
Я кажется видел запрос на определение всех записей в базе.
Вообще он не должен сильно нагружать базу, даже 34 000
но можно сделать и так. Создай в базе еще одну таблицу (или храни в файле и еще как-то) и храни там количество всех записей.
А при добавлении записи увеличивай счетчик на 1.
При удалении уменьшай.

Лично я такие решения не люблю. Но возможно тебе поможет.