Делает внешние ключи представления к MySQL, уменьшают производительность

Вы должны определить внешние ключи. В целом (хотя я не знаю подробностей о mySQL), это не влияет на запросы (а когда есть оптимизатор, такой как оптимизатор на основе затрат в Oracle, он может даже иметь положительный эффект, поскольку оптимизатор может полагаться на информация о внешнем ключе для выбора лучших планов доступа). Что касается влияния на вставку и обновление, то влияние может быть, но получаемые вами преимущества (ссылочная целостность и согласованность данных) намного перевешивают влияние на производительность. Конечно, вы можете разработать систему, которая вообще не будет работать, но основная причина будет заключаться не в том, что вы добавили внешние ключи. А влияние на поддержание кода, когда вы решите использовать какой-либо другой язык, или из-за того, что бизнес-правила немного изменились, или из-за того, что к вашей команде присоединился новый программист и т. Д., Намного дороже, чем влияние на производительность. {{1} } Тогда моя рекомендация - да, идите и определите внешние ключи. Ваш конечный продукт будет более надежным.

Вообще говоря, большее количество ключей (внешних или иных) снижает производительность INSERT/UPDATE и увеличивает производительность SELECT.

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

Нашел похожий запрос здесь: Улучшает ли внешний ключ производительность запроса?

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

Но в то же время добавление внешнего ключа приводит к некоторому снижению производительности. Предполагая, что вы используете INNODB в качестве механизма хранения, он использует кластерный индекс для PK, где по существу данные хранятся вместе с PK. Для доступа к данным с использованием вторичного индекса требуется пройти по дереву вторичного индекса (где узлы содержат PK), а затем второй проход по кластеризованному индексу для фактического извлечения данных. Таким образом, любой DML в родительской таблице, который включает рассматриваемый FK, потребует двух проходов по индексу в дочерней таблице. Конечно, влияние снижения производительности зависит от объема данных, производительности вашего диска, ваших ограничений памяти (кэшированные данные / индекс). Поэтому лучше всего измерять это с учетом вашей целевой системы. Я бы сказал, что лучший способ измерить это с помощью ваших выборочных целевых данных или, по крайней мере, некоторых репрезентативных целевых данных для вашей системы. Затем попробуйте запустить несколько тестов с ограничениями FK и без них. Напишите сценарии на стороне клиента, которые в обоих случаях создают одинаковую нагрузку.

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

Два момента:
1. вы уверены, что проверка целостности на уровне приложения будет лучше с точки зрения производительности?
2. проведите свой собственный тест - тестирование положительного или отрицательного влияния FK на производительность должно быть почти тривиальным.