nIkTo, Да, но очередь будет на стороне MySQL. 

И вообще, если у вас данные поступаю с такой частотой, что MySQL (на данной машине) не успевает их писать в таблицу - вас ничто не спасет от переполнения очереди.

Теперь техническая сторона вопроса: как сделать так что бы MySQL успевал ?
1) проверьте что это вообще возможно на вашей машине:
1.1) пишите в самую простую таблицу без доп. UNIQUE индексов, можно  вообще без индексов.
1.2) почитайте документацию и оптимизируйте буфера MyISAM
1.3) посмотрите (top, iostat, systat) во что упирается система при записи (по идее должна в диск)
1.4) Akina наверняка еще добавит что-то

Если все сделали и все равно очередь растет - у вас слабая машина. 

Кстати та часть скрипта которая пишет в очередь ($insert->enqueue) должна проверять ее наполнение и приостанавливаться если очередь полна.

Это много или мало ?

8 мегабайт? при гектаре на сервере?
Сам-то как думаешь... кстати, по дефолту 16М

1) Многострочная вставка - это правильно. Тут могу порекомендовать написать небольшой тест-скрипт, померить удельную скорость от изменения кол-ва данных в одной пачке именно ваших запросов, имеет смысл попробовать увеличить кол-во. В какой-то момент скорость перестанет расти.


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

2) Основная проблема в ключе по varchar. Вы можете оптимизровать структуру таблицы, завести числовое поле равное какой-нибудь функции от row_name (например, crc32 (int) или половинке от md5 (bigint)), и уникальный ключ строить по ниму. Есть небольшая вероятность коллизий, но оно того стоит.

3) Есть такая фишка - delay_key_write. Если его включить, для данной таблицы или для всех, это в зависимости от значения key_buffer_size снизит вам нагрузку на диск при записи в таблицы. Есть минус - умирание mysql'я приведёт к порче индексов всех таблиц, для которых была включенна отложенная запись ключей. Но это решается myisamchck'ом перед стартом. Работает оно просто - пока есть свободный key_buffer - пишет ключи в момент выполнения запроса в память. Чтобы получить какой-то значимый эффект нужно увеличить key_buffer_size соразмерно кол-ву данных или возможностям хоста. Следить за наполнением буффера ключей можно через show global status like 'key_b%';

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

Замечательный пример. Возьмите tcpdump и посчитайте кол-во пакетов в случае с одним запросом из 2000 строк и 2000 запросов. А теперь умножьте разницу на процент потерь и получится кол-во ретрансмитов, умножьте на задержку в сети и получите время, на которое 2000 запросов дольше одного запроса только лишь из-за сетевых проблем.

Это сообщение отредактировал(а) muzer - 5.10.2010, 12:43