Форум MySQL

Как лучше вставлять данные?..
Разом идёт около 15000 строк(вставка)

В данный момент вставляется всё одним большим запросом.
Какой вариант более подходящий?.

1. Вставка одним запросом (не загнётся ли бд, скушает ли такой большой запрос, если строк будет намного больше?)
2. Вставка несколькими запросами, скажем по 1000
3. Вставка по одной строке:)

Так же вопрос по обновлению записей..
К сожалению нельзя всё сделать одним запросом:( Как быть в такой ситуации?

В данный момент обновление по одной строке за запрос, и можно в реальном времени наблюдать как каждую секунду идёт обновление по 100 штук.. что весьма неприемлимо в моей задаче.. Сразу после обновления пользователь закачивает информацию в ексель файле, но т.к. она ещё не обновлена полностью, инфа будет не той. Как быть?

>1. Вставка одним запросом (не загнётся ли бд, скушает ли такой большой запрос, если строк
>будет намного больше?)
Это зависит от директивы max_allowed_packet, сколько в ней мегабайт указано, такого размера может быть запрос.

>2. Вставка несколькими запросами, скажем по 1000
Это зависит от типа таблицы и обращаются ли к ней в данный момент другие запросы. На момент вставки таблица может полностью блокироваться, в этом случае вставка по 1000 записей будет не плохой идеей.

>3. Вставка по одной строке:)
Если будете вставлять по одной записи или по много записей, но однотабличными запросами, не забудьте отключить ключи - лучше их по окончанию вставки развернуть на уже готовой таблице.

>Так же вопрос по обновлению записей..
А можете описать, что это за таблица? Как в неё попадают данные и какие преимущественно запросы к ней осуществляются?

2. Каким образом заблокировать таблицу и что это может за собой повлечь?

3. Не понял, как отключить, зачем?..

>А можете описать, что это за таблица? Как в неё попадают данные и какие преимущественно запросы к ней осуществляются?

Таблица есть (аттрибуты товаров) пересекаемая с таблицей товаров.. мм Данные попадают после парсинга некого ресурса(сравниваются цены в текущем прайсе с ценами каталога)..
Вообще это висит на кроне ночью, но заказчик пожелал кнопку принудительного парса..
А разве можно както обновить "не по одному" запросу?

>2. Каким образом заблокировать таблицу и что это может за собой повлечь?
Я может не совсем четко выразился, дело в том, что такая массовая вставка будет блокировать таблицу (если это MyISAM-таблица). В момент блокировки все остальные запросы будут ждать, даже если они обращаются к другой части таблицы.

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

>>А можете описать, что это за таблица? Как в неё попадают данные и какие преимущественно запросы к ней осуществляются?
>
>Таблица есть (аттрибуты товаров) пересекаемая с таблицей товаров.. мм Данные попадают после парсинга некого ресурса(сравниваются цены в текущем прайсе с ценами каталога)..
>Вообще это висит на кроне ночью, но заказчик пожелал кнопку принудительного парса..
>А разве можно както обновить "не по одному" запросу?
В вашем случае может имеет смысл строить параллельно рабочей таблице другую временную, отключать в ней индексы на момент вставки, запускать длительные запросы на UPDATE и INSERT, а когда она будет готова, переименовать старую таблицу и новую таким образом, чтобы они обменялись названиями. После чего не спеша удалять таблицу с устаревшими данными.

дык а разница?.. Всё равно после завершения работы скрипта, таблица будет ещё обновляться.. Так или иначе данные будут не те, если начать их скачивать до конца полного обновления...

Возможно, каким либо образом узнать когда всё записалось?.. К примеру чтобы уведомить юзера что операция ещё не закончилась и попросить его подождать.

В смысле обновляться? Что имеется в виду? Вы используете ключевое слово DELAYED?

Вообще способов понять, что же делает СУБД достаточно много, можно, например, проанализировать результат запроса SHOW PROCESSLIST.

нет, в том смысле что записи уже в базе существуют, в них просто изменяется цена, но обновление после завершения работы скрипта идёт не сразу. Можно потом около секунд 10 наблюдать в субд как они меняются порциями.

Это один большой запрос? Тогда он выполняется вероятно достаточно долго, нужно получить его идентификатор (или просто на таблицу ориентироваться) и следить за ним в отчетах оператора SHOW PROCESSLIST - как он там исчезнет, процесс - завершен.

спасибо.

Подскажите ещё пожалуйста насчет нагрузки на базу? Если это всё делать по одному запросу, скажем после получения нового товара(в данный момент просто собирается в массив и в конце скрипта склеивается и отправляется в базу), так по идее обновления будут сразу выполнены уже при завершении скрипта, но не обидится ли бд?

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