| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > MySQL > Автокоммит 1/0 и скорость вставки |
| Автор: d_k 18.3.2016, 15:37 |
| Коллеги, столкнулся с интересной ситуаций. Есть ХП которая переливает данные из одних таблиц (extracted data) в другие (нормализованная структура). Структура такова, есть основная сущность, идет вставка, потом начитываются связанные сущности и вставляются в связанные таблицы с использованием идентификатора полученного от 1-й вставки. Все это обернуто в курсор. Так вот, при выключенном автокоммите и оборачивании вызова ХП в транзакцию скорость вставки порядка 6000 записей в минуту, если включить автокоммит, то скорость вставки вырастает в 3 раза. С чем такое поведение может быть связано? Мне казалось все должно быть как раз наоборот! Если поможет: Записей много, счет на 100-ни миллионов в связанных таблицах (но скорость низкая при выключенном автокоммите и стартанутой транзакции буквально на 1-й сотне тысяч). |
| Автор: Akina 18.3.2016, 16:01 | ||
Гм... а можно полюбопытствовать, почему тебе так казалось? ну просто интересно, каким путём шла мысль человеческая. Как по мне, то записать результат сразу быстрее, чем сперва где-то сохранить, а потом по команде записать, пусть и всё сразу... |
| Автор: d_k 18.3.2016, 16:16 |
| Гм. Ну вроде как по доке все http://docs.oracle.com/cd/E17952_01/refman-5.5-en/optimizing-innodb-transaction-management.html причем все так и есть при балк инсертах, но вот ХП с курсором внутри вкорне меняет положение дел |
| Автор: Akina 18.3.2016, 16:56 | ||
Там общие соображения. А тут мы имеем вполне конкретную ситуацию. Вот мне и интересно, какие именно соображения мануала были отображены на неё, и как именно. Ну и схема ХП не помешала бы - а то не очень ясно, в какие моменты там коммиттятся изменения (более того, создаётся впечатление, что в более быстром варианте транзакций нет вообще). |
| Автор: d_k 21.3.2016, 08:23 | ||
В чем разница? Соображения просты, фиксация делается не после каждого инсерта а некоторыми чанками, что по сути снижает дисковое IO. Нет оверхэда на создание неявных транзакций для каждого инсерта. Схема? Ну суть проста. Открывается курсор внутри ХП. Инсерт в таблицу основной сущности данных курсора (переливка), начитка дочерних записей и их инсерт. И так поциклу до тех пор пока не кончатся записи возвращаемые курсором. Полный код не вижу смысла приводить. ЗЫ: нигде не указал ранее, мой косяк - engine = InnoDb |
| Автор: Zloxa 21.3.2016, 10:30 | ||
Добавлю к сказанному. Незакоммиченное может отлеживаться в различного рода кэшах. Коммит же, прежде чем вернуть управление, обязан дожидаться физического сброса на диск. На версионниках (Oracle, PG, FB) частый коммит очень накладен. InnoDB же, афайк, блокировочник с элементами версионности. Блокировочники изоляцию транзакций обеспечивает созданием дополнительных объектов - блокировок. Для них длинная транзакция (редкий коммит) влечет дополнительные издержки. |
