Снижается ли производительность добавление внешних ключей без принудительного исполнения в базу данных SQL Server 2008?

Это может иметь некоторое влияние, особенно на таких объемах. Однако сначала я бы протестировал это на похожей системе, чтобы вы могли измерить воздействие, если оно есть.

Честно говоря, я бы, вероятно, использовал для этого рукописные хранимые процедуры, чтобы вы могли оптимизировать их по мере необходимости, вместо использования LINQ to SQL.

Ответ может быть разным для разных сред (данные / журналы на одном диске, tempdb на одном диске, много кеша или мало и т. д.), Поэтому лучший способ узнать это - провести тест. Создайте две идентичные базы данных, одну с fk, а другую без. Выполните обычную загрузку миллиона строк в каждую базу данных и измерьте количество транзакций в секунду. Таким образом, вы будете знать наверняка в своей среде.

Я понимаю, что это старый вопрос, но я хочу прокомментировать, насколько плохой является практика создания FK, который не применяется к существующим данным. Если на самом деле требуется внешний ключ, вам необходимо исправить любые неверные данные перед добавлением внешнего ключа (который должен был быть добавлен во время разработки), а не пытаться игнорировать его. Все, что вы делаете, - это маскируете свою очень серьезную проблему целостности данных, отказываясь ее замечать и что-то делать. Иногда в этом возникает необходимость из-за изменившихся требований, но это не следует рассматривать как метод первого выбора при добавлении внешнего ключа в таблицу, содержащую данные. Обнаруживать и исправлять неверные данные следует.

Данные, не имеющие отношения к ПК, бесполезны. Если бы у меня была таблица заказов с идентификатором клиента, которого больше нет в таблице клиентов, как я узнал бы, кто заказал продукт? Конечно, именно поэтому FK следовало применять с самого начала, независимо от того, сделали ли вы вставку миллиона строк или нет. Я ежедневно вставляю многомиллионные строки через SSIS во многие таблицы с внешними ключами, и использование этого в качестве причины для отказа от их настройки в первую очередь указывает на непонимание структуры базы данных. Жертвовать целостностью данных ради скорости ВСЕГДА - плохая идея. Без целостности данных ваша база данных будет ненадежной и, следовательно, бесполезной.

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

Дополнительные индексы снизят производительность ваших операторов вставки / обновления / удаления / слияния и увеличат размеры таблиц.

http://msdn.microsoft.com/en-us/library/ms191195.aspx

Даже когда они созданы с НЕ ДЛЯ ПОВТОРЕНИЯ, индексы все еще присутствуют, и SQL Server должен будет поддерживать их.

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