Использование JDBC: передача данных из tar.gz в базу данных MySQL замедляется после ~ 200 тыс. Записей

Question

В последние дни я довольно долго экспериментировал с целью преобразования структурированных (xml) данных из tar.gz (~ 1,45 млн. Файлов небольшого размера) в более удобный формат в базу данных.

Я не уверен, что я могу раскрыть данные или сценарий использования, но я сделаю все возможное, чтобы объяснить свои усилия.

У меня есть таблица со следующими типами столбцов (MySQL; InnoDB):

int(11) PK NN UQ
varchar(150) NN
varchar(400) NN
text 
text NN
varchar(45) NN UQ
varchar(80) NN
date NN
text 
varchar(300) 
varchar(300) 
varchar(500) 
varchar(260) 
varchar(200) 
varchar(45)

Итерация по всему tar только на просмотр данных + синтаксический анализ занимает примерно 90 секунд +/-:

try (TarArchiveInputStream tarArchiveInputStream =
                     new TarArchiveInputStream(
                             new BufferedInputStream(
                                     new GzipCompressorInputStream(
                                             new FileInputStream(tarLocation))))){

...
    while ((entry = tarArchiveInputStream.getNextTarEntry()) != null && processedTarEntries < maxNumber) {
    ...PARSING + SOME STATISTICS....
    }
}

Я надеюсь, что следующий фрагмент кода будет достаточным для понимания моего итерационного процесса;в противном случае я попытаюсь предоставить больше (totalCount используется в этом примере для генерации искусственного идентификатора).Подготовленный оператор является «нормальным» оператором INSERT INTO.

setPreparedStatementValues(preparedStatement, record, totalCount[0]++);

preparedStatement.addBatch();

counter[0]++;

if (counter[0] == BATCH_SIZE){
    counter[0] = 0;
    preparedStatement.executeBatch();
    connection.commit();
    watch.stop();
    System.out.println("Elapsed time for batch " + (totalCount[0] / BATCH_SIZE) + ": " + watch.getTime());
    watch.reset();
    watch.start();
}

Соответствующая часть вывода sout следующая (размер пакета 5k / 10k действительно не имеет значения):

Elapsed time for batch 29: 3430
Elapsed time for batch 30: 3400
Elapsed time for batch 31: 3553
Elapsed time for batch 32: 3405
Elapsed time for batch 33: 3509
Elapsed time for batch 34: 3544
Elapsed time for batch 35: 6124
Elapsed time for batch 36: 5273
Elapsed time for batch 37: 9171
Elapsed time for batch 38: 8922
Elapsed time for batch 39: 24878
Elapsed time for batch 40: 68124
Elapsed time for batch 41: 70886
Elapsed time for batch 42: 78856
Elapsed time for batch 43: 80879
Elapsed time for batch 44: 85223
Elapsed time for batch 45: 92639
Elapsed time for batch 46: 80106

Время кажется линейным, пока где-то коротко до 40-й партии и не взорвется после этого.Этот вывод взят из эксперимента с максимальным количеством записей 300 тыс., Но я попытался разделить его на две отдельные серии по 150 тыс. Записей каждый.Вывод очень похож на попытку сделать все 300 тыс. За один раз.

Я был бы очень признателен за предложения о том, что я могу сделать неправильно, или за советы, как ускорить это!