Tamanho de transação do MySQL - quão grande é muito grande?

Eu tenho um processo de importação que é executado de vez em quando e quero que seja um tipo de acordo "tudo ou nada", também conhecido como: uma transação.

Existem muitos aspectos, e as importações podem render algo entre 100k-1mil + registros. Isso equivale a uma carga útil que varia de vários MB a algumas centenas de MB de dados.

Eu sei que tabelas temporárias são outra opção - mas esse método parece muito útil.

Há alguma advertência sobre esse tipo de prática com uma grande quantidade de manipulação de dados entre confirmações? (Fora da carga de gravação / indexação típica, uma vez confirmada)

Um gargalo a ser observado é o InnoDB Log Buffer. O tamanho é definido por innodb_log_buffer_size . Aqui está o que a documentação do MySQL diz sobre isso:

O tamanho em bytes do buffer que o InnoDB usa para gravar nos arquivos de log no disco. O valor padrão é 8 MB. Um grande buffer de log permite que grandes transações sejam executadas sem a necessidade de gravar o log no disco antes que as transações sejam confirmadas. Portanto, se você tiver grandes transações, aumentar o buffer de log economizará a E / S do disco.

O InnoDB Log Buffer não deve ser confundido com o InnoDB Buffer Pool. A principal diferença entre eles é o seu propósito. O InnoDB Log Buffer basicamente registra alterações de curto prazo que são gravadas nos logs de refazer (ib_logfile0, ib_logfile1). O InnoDB Buffer Pool (dimensionado por innodb_buffer_pool_size ) armazena em cache os dados e as páginas de índice que devem ser confirmadas (se as páginas estiverem sujas) e eventualmente gravadas) no disco. Uma vez confirmadas, as páginas de alterações permanecem na RAM até serem removidas pelas regras de LRU.

Grandes transações devem canalizar através do Log Buffer. Como mencionado, um buffer de log maior reduzirá a E / S do disco. Somente um grande commit apresentaria um gargalo.

Você pode procurar outras opções do InnoDB para configurar.

• innodb_flush_method : Isso determina como a liberação é tratada e se deve ou não permitir que o sistema operacional armazene em cache gravações no InnoDB ( você deve experimentar entre O_DSYNC e O_DIRECT )
• innodb_read_io_threads (Use o máximo: 64)
• innodb_write_io_threads (Use o máximo: 64)
• innodb_io_capacity (use valores mais altos, como 5000 ou 10000, mas o hardware cobrirá tudo por você. Em outras palavras, deixe o hardware decidir a capacidade de IO depois de atribuir um grande número)
• innodb_thread_concurrency : O valor padrão é 0. Aprendi em primeira mão com Ronald Bradford na Percona NYC 2011 a deixar esse número em 0. Isso permite que o InnoDB decida o melhor número de tickets de simultaneidade que ele poderia manipular)

Tenho outros posts sobre como otimizar o InnoDB para futuras pesquisas

• Otimizando as configurações padrão do InnoDB
• Como você ajusta o MySQL para uma carga de trabalho pesada do InnoDB?
• A tabela InnoDB com inserção pesada não usará toda a minha CPU
• Como melhorar o desempenho do InnoDB DELETE?
• MySql - ibdata1 limpo