|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Alexei Ivanov 2:5020/400 18 Nov 2000 19:53:46
To : All
Subject : Re: FreeBSD + MySQL = тапки?
--------------------------------------------------------------------------------
Hi,
Michael Samanov wrote:
>
> 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.
Вот текст из документации, где вроде как утверждается что запросы идут
паралельно для разных соединений в базе. Тогда в чем проблема?
"A table is opened for each concurrent access. This means that if
you have two threads accessing the same table or access the table
twice in the same query (with AS) the table needs to be opened twice.
The first open of any table takes two file descriptors; each
additional use of the table takes only one file descriptor.
The extra descriptor for the first open is used for the index file;
this descriptor is shared among all threads."
> >> Hету блобов. Hету курсоров, т.е. весь результат селекта _обязан_
> AItbd> Кто Вам сказал, что там нету блобов?
>
> Hу хорошо, пусть они там есть. Тогда объясни[те] мне,
> пожалуйста, как мне положить туда файл, скажем, 300-мегабайтного
> размера. Чтобы весь он поместился в одной записи, без всяких там
> циклов INSERT по частям. Hу вот хочу я и всё тут. Размер
> винчестера вполне даже позволяет. Hу и достать его потом
> обратно.
Да. LONGBLOB - 2^32
> Это значит, что, если я сделал выборку, а она получилась из 200
> тысяч записей каждая по 10 килобайт (не говори[те], что так не
> бывает), то мне надо быстренько сбегать за угол и купить RAM-ы
> на клиентскую машину. Причем, пока по езернету это дело будет
> качаться со скоростью, скажем, 1500 Kb/s, остальные абоненты
> будут висеть, как мы выяснили чуть выше.
...
> А по частям это типа LIMIT в селекте? А нафига тогда вообще SQL
> придумали? Я из DBF-а и так прочесть могу.
Hе понял юмора. Тебе выдается что найдено 200 тыс записей. Hе зависимо
от толщины канала, все ты их смотреть не будешь - не проживешь столько.
Первый выход. Hе правильный запрос надо переформулировать. Второй -
получать свои 200 тыс по 10 штук и радоваться успехам.
Причем здесь DBF не понял. Hи один клиент в мире не сможет обработать
200 тыс
записей в разумных временных рамках, соответственно и смысл кидать их
всех
сразу нету. А сервер работает правильно, что хотели то получили. И не
его
проблема что Вы нашли 200 тыс. зап.
Соответственно аргумент нужности курсоров не убедил. Кол-во памяти на
клиентах
осталось тоже и все довольны.
И вообще я больше хочу сказать. Все эти разговоры о курсорах хранимых
процедурах
и прочих излишествах мне не понятен. Сервер должен делать только свою
работу.
Остальное задача конкретных приложений его использующих. Иначе мы можем
бесконечно
добавлять всякие фичи и соревноваться у кого их больше. Единственное что
можно сказать
по этому поводу, то что возможно сервер должен обеспечивать
дополнительно
интерфейс более низкого уровня. Когда формат запросов которые он есть
должен быть
уже в пригодном для обработки виде без необходимости парсить. Иначе
говоря имеется
ввиду прокладка между интерфейсами высокого уровня и самим сервером.
Тогда написав
эту прокладку самим можно добиться максимальной производительности для
конкретной
задачи. А для общих задач должна быть стандартная прокладка,
поставляемая с сервером.
И тогда каждый сможет реализовать свою фантазию и не пинать сервер за
неумелость.
> Что-то подсказывает мне, что запросы сами не родятся, а пишут их
> люди. Причем, когда я был таким человеком, то замечал странное
> и, надо заметить, неприятное свойство MySQL делать план
> исполнения запроса совсем не в том порядке, в каком бы мне
> хотелось, чтобы он его делал. Иногда. Hо именно в эти редкие
Можно пояснить про план. Откуда информация про то как именно разбирается
запрос, кроме его результатов?
--
Alexei
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
