Сделал ещё ряд тестов.
Точно так же, две таблицы:
- первичный ключ: char(32)+date, партицирование по годам + 3 дополнительных индекса по полям;
- первичный ключ: auto increment+date, партицирование по годам, уникальный ключ char32+date + 3 дополнительных индекса по полям;
В каждой таблице изначально 5 млн строк, в каждом тесте вставлялось по 100 000 новых.
Строки вставлялись по одной и пачками по 20 (среднее кол-во на продакшене за один вызов скрипта).
Запросы делались по одному, без оборачивания в транзакцию (насколько я понимаю, если запрос один - то и транзакция бесполезна, независимо от кол-ва строк?).
В результате получено ускорение в 2,6 раз:
- 0,010 сек с суррогатным и 0,026 сек с char(32) построчно;
- 0,003 и 0,007 по 20 строк за запрос.
Кроме этого, batch-запросы с auto increment имеют намного меньшее max время вставки: 1,5 сек против 11,4 (да, 11 секунд на вставку 20 строк).
Также при заполнении таблиц тестовыми данными (5 млн строк на каждую), auto increment показал в ~2.3 раза больше скорость и в целом скорость держалась +- стабильной, когда как для первичного char(32) ключа она постоянно падала вместе с заполнением таблицы.
В целом можно сказать, что да, суррогатный первичный ключ действительно сильно ускоряет вставку по сравнению с char(32).
Простой