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

Ответ 1

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

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

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

Честно говоря, я бы взял копию вашей базы данных, добавил правильно индексированные FK и покажу разницу во времени, чтобы вставлять, удалять, обновлять и выбирать из этих таблиц в сравнении с тем же из вашей базы данных без FK. Покажите, что вы не будете наносить удар производительности. Затем покажите результаты запросов, которые показывают осиротевшие записи, которые больше не имеют значения, потому что ПК, к которым они связаны, больше не существует. Особенно эффективно показывать это для таблиц, содержащих финансовую информацию ( "У нас есть 2700 заказов, которые мы не можем связать с клиентом" заставит руководство сидеть и принимать к сведению).

Ответ 2

Из Шаблоны и методы Microsoft: Глава 14 Улучшение производительности SQL Server:

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

Ответ 3

Это скорее политическая проблема, чем техническая. Если ваше управление проектом не видит никакой ценности в поддержании целостности ваших данных, вам нужно быть в другом проекте.

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

Ответ 4

Кто-нибудь знает о сравнении, контрольном показателе или подобном, что доказывает, что значительная производительность не влияет на использование внешних ключей? (Который, я надеюсь, убедит его)

Я думаю, вы идете по этому неправильно. Тесты никогда не убеждают кого-либо.

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

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

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

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

Ответ 5

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

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

Что касается недопустимых ссылок ar, если вы не разрешаете null на внешних ключах, вы не получите недопустимых ссылок. База данных будет выполняться, если вы попытаетесь присвоить недопустимый внешний ключ, который не существует. Если вам нужны "нули", назначьте ключ "UNDEFINED" или что-то в этом роде и сделайте этот ключ по умолчанию.

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

Ответ 6

Значимым фактором в стоимости будет размер индекса, который ссылается на внешний ключ - если он будет мал и часто используется, влияние производительности будет незначительным, большие и менее часто используемые индексы будут иметь большее влияние, но если ваши иностранные ключ против кластеризованного индекса, он все равно не должен быть огромным хитом, но @Ronald Bouman прав - вам нужно протестировать, чтобы быть уверенным.