ru.unix

 
 - RU.UNIX ----------------------------------------------------------------------
 From : Michael Samanov                      2:550/5068.1515 18 Nov 2000  07:04:48
 To : A.Ivanov@tu-bs.de
 Subject : Re: FreeBSD + MySQL = тапки?
 -------------------------------------------------------------------------------- 
 

 Hello, A.Ivanov@tu-bs.de!
 
 At Sat, 18 Nov 00 03:48:41 +0300 A.Ivanov@tu-bs.de wrote:
 
 AItbd> Можно объяснить фразу "один большой селект вешает остальных клиентов".
 
 Можно. Делаю я, скажем, select ... insert into ... секунд эдак на
 десять, а другой дяденька (тетенька, смысл от этого не меняется)
 хочет сделать маленький селект на пару строк, причем строго по
 индексу. Его (ее) запрос выполняется, скажем, за 50 ms, но ждать
 он (она) будет все десять секунд. Это как раз из реальной
 задачи, после безуспешного решения которой я и перешел на
 Interbase.
 
 AItbd> Что меняется если все запросы выполняются паралельно?
 AItbd> Как мне кажется общее время выполнения каждого запроса при этом
 AItbd> увеличится.
 
 Да это просто-таки несомненно. Разумеется, в dedicated mode
 работает быстрее. Для простоты объяснений того, что именно
 меняется, могу предложить сравнить удобство работы в поочередном
 DOS и одновременном UNIX.
 
 AItbd> Тогда что мы выигрываем?
 
 Всемирный чемпионат по футболу. Hо это все мечты...
 
 >> Hету блобов. Hету курсоров, т.е. весь результат селекта _обязан_
 AItbd> Кто Вам сказал, что там нету блобов?
 
 Hу хорошо, пусть они там есть. Тогда объясни[те] мне,
 пожалуйста, как мне положить туда файл, скажем, 300-мегабайтного
 размера. Чтобы весь он поместился в одной записи, без всяких там
 циклов INSERT по частям. Hу вот хочу я и всё тут. Размер
 винчестера вполне даже позволяет. Hу и достать его потом
 обратно.
 
 AItbd> Что такое курсор. Смысл?
 
 См. чуть ниже.
 
 >> целиком вместиться в память клиента. Hету ручной оптимизации
 AItbd> Что значит результат должен вместиться в память клиента?
 
 Это значит, что, если я сделал выборку, а она получилась из 200
 тысяч записей каждая по 10 килобайт (не говори[те], что так не
 бывает), то мне надо быстренько сбегать за угол и купить RAM-ы
 на клиентскую машину. Причем, пока по езернету это дело будет
 качаться со скоростью, скажем, 1500 Kb/s, остальные абоненты
 будут висеть, как мы выяснили чуть выше.
 
 AItbd> Что я ищу, то и получаю. Если я не могу поднять два мешка картошки, то
 AItbd> нефиг их и покупать.
 
 Если уж сравнивать с картошкой, то ее можно таскать не только
 мешками, но и авоськами и даже поштучно. Перетаскивать таким
 образом можно тонны картошки, не особо натруждая спину.
 
 AItbd> В конце концов предоставляй возможность при получении
 AItbd> более какого-то
 AItbd> кол-ва записей просматривать их по частям.
 
 Так вот, имеючи курсор, я могу совершенно спокойно, без суеты и
 напряга, построчно читать мою выборку. А как я могу заранее
 знать, сколько строк в ней будет? А если мне надо всю таблицу
 прошерстить? Бежать покупать оперативки объемом с винчестер?
 А по частям это типа LIMIT в селекте? А нафига тогда вообще SQL
 придумали? Я из DBF-а и так прочесть могу.
 
 >> запросов (EXECUTE PLAN), что есть, например, в интербейсе.
 AItbd> По поводу оптимизации запросов - наверно хорошо, но когда их много и они
 AItbd> разные
 AItbd> смысла нет.
 
 Что-то подсказывает мне, что запросы сами не родятся, а пишут их
 люди. Причем, когда я был таким человеком, то замечал странное
 и, надо заметить, неприятное свойство MySQL делать план
 исполнения запроса совсем не в том порядке, в каком бы мне
 хотелось, чтобы он его делал. Иногда. Hо именно в эти редкие
 минуты мне было невыносимо грустно.
 
 Sincerely yours, Michael (mailto:mike@vlink.ru).
 --- ifmail v.2.14
  * Origin: Mike's home (2:550/5068.1515@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор