Новости
Документация
Download
Webboard
Поиск
FAQ/ЧаВо
Обратная связь




MySQL.RU - Webboard



Вернуться
Оптимизация БД (Чебурашка :)) 08/08/2004 - 05:10:56
      Re: Или я не понял, или одно из двух.. (Lev) 08/08/2004 - 08:04:13
      Re: Или я не понял, или одно из двух.. (Чебурашка) 09/08/2004 - 01:33:07
      Re: Или я не понял, или одно из двух.. (Lev) 09/08/2004 - 04:38:41
      Re: Кстати (Lev) 09/08/2004 - 04:39:32
      Re: Или я не понял, или одно из двух.. (Чебурашка) 09/08/2004 - 04:57:50
      Re: Учиться, учиться и еще раз... (Lev) 09/08/2004 - 12:02:47
      Re: Учиться, учиться и еще раз... (Dinky) 09/08/2004 - 19:08:54
      Re: А причем тут :) ?? (Lev) 09/08/2004 - 19:57:30
      Re: А причем тут :) ?? (Dinky) 09/08/2004 - 21:57:50
      Re: сделаем выводы (Валентин) 10/08/2004 - 14:03:26
      Re: Закроем вопрос (Lev) 10/08/2004 - 21:23:26
      Re: Учиться, учиться и еще раз... (nt7714) 16/11/2008 - 15:34:17

> Original message text:
> From: Чебурашка :) - 08/08/2004 - 05:10:56
> Subject:Оптимизация БД
> -----------------
> Вот такая штука меня интересует, есь большая БД (50000 строк), задаём параметр insert id from flag WHERE ru=50000 limit 1 и чё мы видим, что бы вытащить последний id наша БД начинает переберать все строки начиная с ru=1, перебрав 50000 строк находит последнию.
> Вопрос, как настроить БД чтобы она начинала перебор с последних добавленных строк? А не прочёсывая весь архив.
>


From: Lev - 09/08/2004 - 12:02:47
Subject:Учиться, учиться и еще раз...
-----------------
Честно говоря, не вижу смысла обсуждать тему дальше… Но на последок я скажу. То что думаю.
1)Наверное естественно, что отбор 30 первых (относительно чего первых???!!) записей времени надо меньше, чем на отбор последних. Потому что, что бы понять какие из записей «последние» – надо наверное ВЕСЬ набор записей сперва создать, а потом из него взять 30 последних… А может еще чем объясняется… - может кто из знатоков серверной технологии скажет. А в случае отбора "первых" - отбирай первые попавшиеся 30 штук и плевать, сколько еще их там неотобранных осталось!
2)В любом случае, если вы ищете единственную запись «… WHERE ru=50000» и поле ru ИНДЕКСИРОВАНО – сервер НЕ ПЕРЕБИРАЕТ записи! а отбирает эту единственную, ну может группу, у которой ru=50000.
Другое дело, что на обработку индексов поди тоже время нужно!
3)что бы на 50000 записей иметь 60мегов – надо кроме ru еще чтонить в записях иметь… У меня в табличке 60000, и куча других таблиц по 5…5000 записей – имеем 16 мегов (таблицы MyISAM). Думаю, говорить о соотношении мегов и числа записей без оговорки структуры Бд безсмысленно.
4)у меня из таблицы 140000 записей отбор нужных 65шт по фильтру идет одинаково быстро (или если хотите – одинаково меделенно, как больше нравится) вне зависимости от возраста записей (старые/новые).
5) сусять раз уже говорено, что для сервера нет понятия «первые» записи и «последние» записи. Читайте теорию! Порядок записей может существовать лишь в контексте вашего рекордсета – как он сформируется – ваша забота (типа там ORDER BY…), а иначе сервер отбирает записи в случайном порядке, и самая свежая запись запросто может быть и последней и первой …
«…Откуда MySQL начинает перебор для поиска ru = 50 000, с начала, начало у неё где ?» – у кого «У НЕЕ»??? у таблицы? НЕТ У НЕЕ НАЧАЛА!
6)насчет «команда, запрещающая перебор в случае нахождения параметра» – формируйте запросы точно, минимизируйте набор записей. Это Ваша забота, а сервер лишь исполняет ваши прихоти! Другое дело, что для того чтобы отобрать заказанные записи, сервер просматривает все записи (или в случае наличия индексов – ищет группу записей по индексу) – но это, насколько я понимаю, технология работы сервера, пока он эту работу не выполнит - его нельзя «прерывать» - а может «дальше» еще найдется что-то.
7)и если уж на то пошло… а какая разница юзеру по времени 0,0001 или 0,1000 – если это не в цикле… У любого нормального юзера реакция все равно медленнее, думаю в этих пределах никто особо разницы и не заметит, тем паче сеть все подровняет! Совсем другое дело 0,1 сек и 5 сек !!! - тут есть с чем бороться.
Или может вы разрабатываете АСУТП???? но тогда вроде для оперативных, критичных по времени дел MySQL не используют



[Это сообщение - спам!]

Последние сообщения из форума

Уважаемые посетители форума MySQL.RU!
Убедительная просьба, прежде чем задавать свой вопрос в этом форуме, обратите внимание на разделы:
- ответы на наиболее часто задаваемые вопросы - FAQ
- раздел документация
- раздел поиск по сообщениям форума и документации
Также, старайтесь наиболее подробно указывать свою ситуацию (версию операционной системы, версию MySQL, версию программного обеспечения, по которому возникает вопрос, текст возникающих ошибок, и др.)
Помните, чем конкретнее Вы опишете ситуацию, тем больше шансов получить реальную помощь.
 Имя:
 E-mail:
 Тема:
 Текст:
Код подтверждения отправки: Code
34524



РЕКЛАМА НА САЙТЕ
  Создание сайтов | |