Это мой провайдер мне сообщил! Это результат. А что для этого надо? У меня в базе каталога 34000 строки и 10 полей  Может на perl перевести для быстроты ?   

Это сообщение отредактировал(а) kshyms - 31.12.2008, 17:59

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

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

вопрос решен

Это сообщение отредактировал(а) kshyms - 30.1.2009, 11:44

kshyms, то что ты привел конечно интересно, но не мог бы ты сам вытащить из своего кода sql запросы, привести структуру таблицы и пояснить что каким запросом пытаешься вытащить, как потом результат используешь и почему именно так. Это поможет людям быстрее понять что у тебя возможно оптимизировать и дать дельный совет.

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

аналогично оптимизировать это

да не увидел у тебя защиту от SQL-инекций

Это сообщение отредактировал(а) krundetz - 31.12.2008, 18:15

Я понял надо загружать не все подряд, а только то, что надо! Это и будет оптимизацией запросов к базе...

Это сообщение отредактировал(а) kshyms - 1.1.2009, 16:45

На сколько я знаю нужно наоборот count(*) делать для оптимизации.
Поскольку так оно считает только строки в таблице, не выбирая значения вообще.
А если считать по конкретному столбцу, то сначала выбираются значения не нулевые и возвращается их количество.
Потому запрос

Будет быстрее чем

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

Здесь вычитал про оптимизацию а может limit для загрузки строк применить и разбить таблицу на несколько частей и по очереди как новый запрос загружать и еще лишние поля убрать которые не используются?
А может заменить SELECT COUNT(*) ... на select_expression (Выражение select_expression задает столбцы, в которых необходимо проводить выборку) будет ли быстрее работать?

Это сообщение отредактировал(а) kshyms - 2.1.2009, 08:10

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

Я уверен что нет.

А ты его что совсем не применял?

Если ты имеешь в виду разбить таблицу на несколько таких же то могу сказать вот что. НИКОГДА ДАЖЕ НЕ ДУМАЙ так делать. Это вообще сумасшествие какое то...

Определенно да.

не совсем понял данное высказывание.
Если у нас таблица скажем на 100000 строк и постоянно мы оперируем только 1000 последних, то само по себе напрашивается разделение таблицы на две постоянно запрашиваемых и обновляемых данных и архивной где данные обновляются и запрашиваются крайне редко!

kshyms говорил про 34000 полей.
На моем компьютере, который не ровня серверам, запрос на выборку из 40 000 меньше секунды уходит. А он говорил про 10 сек.
Про разбивание таблиц с его слов я понял что он хочет на несколько разбивать (больше 2)
Смысл в разбиении таблицы на 2 я вижу в том случае если 2-я это сбор всех данных. В 1-ю мы добавляем новые. И периодически из 1-й мы переводим данные во 2-ю. Это уменьшает нагрузку. Поскольку затрагивается основная база не каждый раз когда происходит обновление.
Такой способ часто встречается в очень нагруженных сайтах , а именно в голосовании.
Пример таблицы в которой часть данных часто используется а основная масса нет, я на своей практике не встречал.
Меня еще заинтересовало каким образом определяется какие записи более востребованы.
Я понимаю так. У каждой ячейки есть счетчик количества запросов к ней. И если он переходит границу то запись мигрирует из главной таблицы в более используемую.
Я такого не встречал. Наведите пожалуйста примеры сайтов где используется такой способ?
Еще разденление таблици на несколько неизбежно ведет к множеству  проблем. Например поиск по сайту должен осуществятся сразу по нескольким таблицам (вместо одной) и это только вершина айсберга.
Потому разбиение на 2 таблицы я вижу только в том случае если это правда оправданный ход. И перед действием стоит очень серьезно подумать.

Это сообщение отредактировал(а) taral - 5.1.2009, 01:49

финансовые данные, работа с данными отчетного периода
трейдерские данные, опят же периодичность работы с данными
новости

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

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

Чат?..
Архивные данные для восстановления справедливости в конфликтных ситуациях.