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

Question

Я работаю с базой данных и хочу начать использовать с ней LINQ To SQL. В настоящее время в базе данных нет никаких FK внутри нее по соображениям производительности. Мы вставляем миллионы строк одновременно в БД, поэтому здесь нет FK.

Так что я думаю, что собираюсь добавить неисполнимые FK в базу данных, чтобы описать отношения между таблицами для моего LINQ To SQL, но я не хочу, чтобы при снижении производительности добавлялись неиспользуемые внешние ключи.

Кто-нибудь знает, какой это может быть эффект?

Обновление: я использую LINQ-To-SQL для неэффективного информативного материала. 80% доступа к данным осуществляется через хранимые процедуры на производстве. Но для написания модульных тестов и других задач, не критичных к производительности, LINQ-To-SQL делает доступ к данным действительно простым.

Обновление: вот как вы добавляете неисполненный FK

ALTER TABLE [dbo]. [ACI] с NOCHECK ADD CONSTRAINT [FK_ACI_CustomerInformation] FOREIGN KEY ([ACIOI]) ССЫЛКИ [dbo]. [CustomerInformation] ([ACI_OI]) НЕ ДЛЯ РЕПЛИКАЦИИ GO

ALTER TABLE [dbo]. [ACI] NOCHECK CONSTRAINT [FK_ACI_CustomerInformation] GO

Answer 1

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

Answer 2

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

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

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

Даже если они созданы с параметром NOT FOR REPLICATION, индексы все еще присутствуют, и SQL Server потребуется их поддерживать.

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

Answer 3

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

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

Answer 4

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

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