В отношениях один к нулю/один (MySQL, InnoDB) есть ли какие-либо улучшения производительности за счет использования внешнего ключа в качестве первичного ключа?
Итак, чтение этого старого Сообщение блога (который, честно говоря, довольно старый) дало мне некоторые мысли о том, как структурировать некоторые из моих связей между таблицами.
Если какой-либо поиск по вторичному индексу содержит первичный ключ, а первичный ключ — это то, что обращается к данным строки, то для такого рода схемы
Users : id, name, country, etc.
User_Mailboxes : id, user_id, location, height, etc.
Если у пользователя может быть или не быть почтовый ящик, но не более одного, было бы более эффективно избавиться от «идентификатора» в качестве первичного ключа таблицы user_mailboxes и установить внешний ключ в качестве первичного ключа?
Насколько я понимаю InnoDB, таким образом мы сохранили бы любые поиски вторичного индекса для соответствующего первичного ключа и могли бы напрямую использовать User.id для поиска соответствующей информации о почтовом ящике.
Так что что-то более похожее на это,
Users : id (PRIMARY), name, country, etc.
User_Mailboxes : user_id(FOREIGN, PRIMARY), location, height, etc.
Должен ли быть немного более производительным с точки зрения хранения индекса и случайного поиска? Особенно, если я рассматриваю возможность одновременного захвата нескольких почтовых ящиков на основе некоторых пользовательских критериев?
Ответы 2
В отношениях 1:0..1 вы можете (и должны) делать это, да. Я бы тоже так сделал. Хранить ненужную информацию в любом случае нехорошо.
Но не разочаровывайтесь, если вы не получите столько производительности, как вы думаете. Когда вы не захватываете действительно большое количество пользователей/почтовых ящиков одновременно, вы не заметите многого или вообще ничего.
FOREIGN KEYзамедляет вставляется из-за выполненной проверки. (Но это незначительный удар по производительности.)Ничто не «требует» существования каких-либо ФК. (Кроме некоторых учебников.)
FOREIGN KEYнеявно создаетINDEX(если он еще не существует).INDEXesможет иметь большое значение для производительностиSELECTs.Этот трюк может переместить «важные» запросы в
PRIMARY KEY. Хитрость заставляет выборку по диапазону в PK использовать преимущества кластеризации.-- Instead of PRIMARY KEY (id), INDEX (foo) -- change to PRIMARY KEY (foo, id), -- `id` included to achieve UNIQUEness INDEX (id) -- to keep AUTO_INCREMENT happyЕсли у вас есть «естественный» первичный ключ, используйте его и выбросьте auto_increment. (В некоторых случаях это помогает в целом; в некоторых случаях это вредит.)
Покажите нам важные запросы.