Размер транзакции MySQL - насколько большой слишком большой?

У меня есть процесс импорта, который запускается очень часто, и я хочу, чтобы это была сделка типа «все или ничего», то есть транзакция.

Есть много аспектов, и импорт может дать где-то между 100k-1mil + записей. Это соответствует полезной нагрузке от нескольких МБ до нескольких сотен МБ данных.

Я знаю, временные таблицы - еще один вариант, но этот метод кажется очень удобным.

Есть ли какие-то предостережения относительно такого рода практики с большим количеством манипуляций с данными между коммитами? (За пределами типичного пакета загрузки при записи / индексировании после фиксации)

— тонкий лед
источник

Лично мне нравится иметь баланс. Я делаю импорт в транзакциях 1к или 10к, потому что я просто знаю, что он достигнет примерно 900 тыс. Строк, а затем потерпит крах из-за размера буфера или чего-то еще смешного. Довольно легко получить от этого, и не так много ввода-вывода.

— Капитан Гипертекст

Одним из узких мест, о которых следует знать, является буфер журналов InnoDB. Размер устанавливается innodb_log_buffer_size . Вот что говорит об этом документация MySQL:

Размер в байтах буфера, который InnoDB использует для записи в файлы журналов на диске. Значение по умолчанию составляет 8 МБ. Большой буфер журнала позволяет выполнять большие транзакции без необходимости записывать журнал на диск до фиксации транзакций. Таким образом, если у вас большие транзакции, увеличение размера буфера журнала экономит дисковый ввод-вывод.

Не следует путать буфер журнала InnoDB с пулом буферов InnoDB. Основное различие между ними заключается в их предназначении. InnoDB Log Buffer будет в основном записывать кратковременные изменения, которые записываются в журналы повторов (ib_logfile0, ib_logfile1). Буферный пул InnoDB (по размеру innodb_buffer_pool_size ) кэширует страницы данных и индексов, которые должны быть зафиксированы (если страницы загрязнены) и в конечном итоге записаны) на диск. После подтверждения страницы изменений остаются в оперативной памяти до тех пор, пока не будут удалены с помощью правил LRU.

Большие транзакции должны проходить через Log Buffer. Как уже упоминалось, больший буфер журнала уменьшит дисковый ввод-вывод. Узкое место может представлять только большой коммит.

Возможно, вы захотите посмотреть другие параметры InnoDB для настройки.

innodb_flush_method : это определяет, как обрабатывается сброс, и разрешать ли ОС кэшировать записи в InnoDB ( вы должны поэкспериментировать между O_DSYNC и O_DIRECT )
innodb_read_io_threads (используйте максимум : 64)
innodb_write_io_threads (используйте максимум : 64)
innodb_io_capacity (используйте более высокие значения, такие как 5000 или 10000, но аппаратное обеспечение превзойдет его, другими словами, пусть аппаратное обеспечение определит емкость ввода-вывода после того, как вы назначите огромное число)
innodb_thread_concurrency : значение по умолчанию равно 0. Я воочию узнал от Рональда Брэдфорда из Percona NYC 2011, что нужно оставить это число равным 0. Это позволяет InnoDB выбирать лучшее количество заявок на параллелизм, которые он может обработать)

У меня есть другие посты об оптимизации InnoDB для дальнейшего исследования

— RolandoMySQLDBA
источник

как-то я знал, что ты будешь на этом. Спасибо за подробные ответы, которые вы, кажется, всегда даете. Дополнительный вопрос: есть ли у вас какие-либо ресурсы относительно использования innodb_io_capacity? Когда документация предполагает, что потребительские SATA 5400/7200 об / мин имеют значение 100, вы предлагаете свою стратегию просто «снять ограничение», установив это значение так высоко?

— худой

Я обычно устанавливаю innodb_io_capacity выше и позволяю аппаратным средствам увеличить его. Я добавлю это к моему ответу прямо сейчас.

— RolandoMySQLDBA