Каковы различия в производительности между запуском One и многими вставками?

Question

В настоящее время я нахожусь в ситуации, когда я создаю скрипт, который, как я знаю, должен будет вставить несколько строк.Я делаю это в Perl, так что с точки зрения параметризации намного проще вставлять каждую строку отдельно.С точки зрения скорости, я предполагаю, что выполнение только одного оператора вставки будет быстрее (хотя задержка будет относительно низкой, поскольку я довольно близок к самой базе данных).Я думаю, что количество строк в сценарии будет в среднем около 20-40.Тем не менее, каковы будут приблизительные различия в производительности между выполнением всего лишь одного оператора INSERT INTO и выполнением по одному для каждой строки?Примечание. На сервере запущен SQL 2008.

[РЕДАКТИРОВАТЬ] Поскольку, как представляется, существует большая путаница, я хотел бы пояснить, что на самом деле я спрашиваю теорию о том, какВставка строк обрабатывается SQL Server 2008. По сути, он просто конвертирует его внутри в набор отдельных операторов вставки и выполняет их по одному соединению, или он делает что-то более интеллектуальное?

Да, я знаю, что могузапустить синхронизированные циклы.Нет, я не об этом.[/ EDIT]

Answer 1

Объединение нескольких вставок в одну команду всегда будет выполнять намного быстрее, чем выполнение отдельных вставок. Причины:

• A много работы выполнено синтаксический анализ SQL - с многоверсионной версией, есть только one попытка синтаксического анализа
• Проделана дополнительная работа по проверке разрешений - опять же, только выполнено один раз
• Соединения с базой данных "болтливы" - в случае нескольких версий рукопожатие выполняется только один раз. Вы действительно замечаете эту проблему, когда используете плохое сетевое соединение
• Наконец, многоверсия позволяет серверу оптимизировать работу

Answer 2

Существует общая идея позволить базе данных SQL делать свое дело, а не пытаться рассматривать базу данных как своего рода чтение с диска. Я много раз видел, как разработчик будет читать из одной таблицы, затем из другой, или делать общий запрос, а затем пробежаться по каждой строке, чтобы узнать, нужна ли она. Как правило, лучше позволить базе данных SQL делать свое дело.

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

Нетрудно создать временную базу данных и попробовать ее. Создайте базу данных с двумя столбцами и попросите программу сгенерировать данные для добавления в таблицы. Дайте себе приличную сумму, чтобы сделать. Например, сколько предметов будет в этой таблице? И сколько вы думаете, вы будете вставлять сразу? Скажем, создайте таблицу из 1 000 000 элементов и вставьте в нее 1000 элементов за раз, 100 элементов за раз и один элемент за раз. Просто сгенерируйте данные, используя оператор приращения. Может быть «конфетка» из количества предметов, которые вы можете вставить одновременно.

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

У меня есть программное изречение: Место, где вы хотите оптимизировать свой код, вероятно, не в том месте . Нам нравится эффективность, но мы обычно нападаем не на тот предмет. И, что бы мы ни выдавали в плане эффективности, мы теряем затраты на обслуживание.

Итак, просто запрограммируйте то, что легче всего понять, и не беспокойтесь о чрезмерной эффективности.

Answer 3

Просто добавим пару других различий производительности, о которых стоит подумать при вставке:

• Внешние ключи - Если таблица, в которую вы вставляете, имеет внешние ключи, SQL Server фактически должен присоединиться к таблицам внешних ключей при вставке. Когда вы выполняете вставки в одном запросе, SQL-сервер может более эффективно выполнять эти объединения.

• Транзакции - Поскольку вы не упоминаете транзакции, я предполагаю, что вы должны использовать режим автоматической фиксации SQL Server. При таком небольшом количестве строк вполне вероятно, что затраты на создание 40 транзакций против 1 транзакции будут выше, чем поддержка журнала, чтобы разрешить откат. Однако, если бы вы вставляли 400000 строк, вероятно, было бы дороже вставить в одну инструкцию / транзакцию, чем вставить 400000 отдельных строк, поскольку затраты на подготовку к откату до 400000 строк очень высоки (если бы вы вставили 400000 ряды, как правило, лучше всего вставлять партиями -> оптимальный размер партии можно определить путем тестирования). Кроме того, при превышении определенного количества строк может стать более эффективным отключение внешних ключей, вставка строк и их повторное включение.