В отношении один к нулю / один (MySQL, InnoDB), есть ли улучшения производительности при использовании внешнего ключа в качестве первичного ключа? - PullRequest
Новая
       11

В отношении один к нулю / один (MySQL, InnoDB), есть ли улучшения производительности при использовании внешнего ключа в качестве первичного ключа?

2 голосов
/ 16 мая 2019

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

Users : id, name, country, etc.

User_Mailboxes : id, user_id, location, height, etc.

Где пользователь может иметь или не иметь почтовый ящик, но не более одного, будет ли онболее эффективно избавиться от 'id' как первичного ключа таблицы user_mailboxes и установить внешний ключ в качестве первичного ключа?

Исходя из моего понимания InnoDB, таким образом мы сохраним любые вторичные индексы, ищем соответствующий первичный ключ и сможем напрямую использовать User.id для поиска соответствующей информации о почтовом ящике.

Так что-то более похожее на это 

Users : id (PRIMARY), name, country, etc.

User_Mailboxes : user_id(FOREIGN, PRIMARY), location, height, etc.

Должно ли быть немного более производительным с точки зрения хранения индекса и случайного поиска?Особенно, если я собираюсь захватить сразу несколько почтовых ящиков на основании некоторых пользовательских критериев?

Ответы [ 2 ]

1 голос
/ 16 мая 2019

В отношениях 1: 0..1 вы можете (и должны) делать это, да.Я бы тоже так сделал.Хранить ненужную информацию в любом случае нехорошо.
Но не разочаровывайтесь, когда вы не получаете столько производительности, сколько думаете.Когда вы не захватываете действительно большое количество пользователей / почтовых ящиков сразу, вы не заметите ничего или вообще ничего.

0 голосов
/ 26 мая 2019

  • A FOREIGN KEY замедляет вставку из-за выполненной проверки.(Но это незначительный удар по производительности.)

  • Ничто не "требует" существования каких-либо ФК.(За исключением некоторых учебников.)

  • A FOREIGN KEY неявно создает INDEX (если он еще не существует).

  • INDEXes может существенно повлиять на производительность SELECTs.

  • Этот трюк может сместить «важные» запросы на PRIMARY KEY.Хитрость заключается в том, что выборка по дальности для ПК использует преимущества кластеризации. 

      -- 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.(В некоторых случаях это помогает в целом; в некоторых случаях это больно.)

...