Что лучше, множество запросов на вставку в одной транзакции или один запрос на вставку всех значений?

Question

[ikutin]

Что лучше в плане оптимизации вставки, все запросы выполняются в одной транзакции, собственно вот вопрос

INSERT INTO
    Person (Id, Name)
VALUES
    (1, 'Amir' ),
    (2, 'Sofia'),
    (3, 'Aya'),

или же

INSERT INTO Person VALUES (1, "Amir");
INSERT INTO Person VALUES (2, "Sofia");
INSERT INTO Person VALUES (3, "Aya");

и как на производительность влияет onConflict?

и какие есть практики когда за раз надо много вставить строк(без использования copy)

Comments

[szQocks]

Что лучше, множество запросов на вставку в одной транзакции или один запрос на вставку всех значений?

конечно в одной транзации, но не одним скорее всего запросом если данных много

Answer 1

[mayton2019]

В реальной жизни ты должен использовать второй варинт. Потому что - транзакции.
Ими надо управлять. И приложение типа CRUD тоже должно всегда использовать второй вариант.

Первый вариант - скорее всего применим при массовых загрузках. Например при создании БД. При миграции.
И еще может быть при выполнении каких-то maintenance задач.
Обычно в этом случае - отключают триггеры, индексы и грузят на максималках. А уже потом
последовательно включают и смотрят что валидация прошла успешно.

Comments

[freeExec]

Второй вариант из заголовка или из вопроса?

[Евгений Залецкий]

freeExec, второй вариант, а не вопрос из заголовка

Answer 2

[rPman]

Эти два метода вставки не идентичны, в ситуациях с ошибками вставки данных (например ошибка уникальности индекса или любой другой constrainit) до окончания транзакции, в первом случае никакие данные не будут записаны, а во втором, будут записаны данные до возникновения ошибки. Понятно что если все завернуть в единую транзакцию и при возникновении ошибки эту транзакцию отменять, то тогда содержимое базы будет идентично. Но когда речь идет об нестандартных способах обработки ошибок, второй вариант может оказаться удобнее, ведь можно пожелать продолжить вставку данных, с пропуском ошибочных... когда как первый вариант такого не позволит (сообщение об ошибке может даже не сообщить идентификатор, с которым произошла проблема, а если и будет такая информация, то только по одной записи)

В общем первый вариант идеален, если контроль за целостностью данных отключен или точно известно, что данные не противоречивы. Тут и скорость и синтаксическая простота, и меньше места sql занимает.

Иначе, лучше второй вариант.