Чи іноземний ключ автоматично створює індекс?

Мені сказали, що якщо я вкажу дві таблиці, SQL Server створить щось подібне до індексу в дочірній таблиці. Мені важко вірити, що це правда, але я не можу знайти багато, що стосується конкретно цього.

Моя реальна причина запитати це тому, що ми відчуваємо дуже повільний час відповіді в операторі видалення проти таблиці, на якій, мабуть, 15 пов'язаних таблиць. Я запитав нашого хлопця з бази даних, і він каже, що якщо на полях є зовнішній ключ, то він діє як індекс. Який у вас досвід цього? Чи слід додати індекси на всі закордонні ключові поля чи вони просто непотрібні накладні витрати?

Іноземний ключ - це обмеження, відношення між двома таблицями - яке не має нічого спільного з індексом як таке.

Але відомий факт, що має сенс індексувати всі стовпці, які є частиною будь-якого зовнішнього ключа, оскільки через FK-зв’язок вам часто потрібно буде шукати відповідну таблицю та витягувати певні рядки на основі одне значення або діапазон значень.

Отже, має сенс індексувати будь-які стовпці, що беруть участь у ФК, але ФК сам по собі не є індексом.

Перегляньте чудову статтю Кімберлі Тріппа "Коли SQL Server перестав ставити індекси на стовпці іноземних ключів?" .

Нічого собі, відповіді по всій карті. Отже, Документація говорить:

Обмеження ЗАМЕЧЛЕНОГО КЛЮЧА є кандидатом на показник, оскільки:

• Зміни в обмеженнях PRIMARY KEY перевіряються обмеженнями FOREIGN KEY у відповідних таблицях.

• Стовпці із зовнішнім ключем часто використовуються в критеріях приєднання, коли дані із пов’язаних таблиць поєднуються у запитах, шляхом зіставлення стовпців (ив) обмеженням ІНТЕРНЕТ-КЛЮЧ однієї таблиці з первинним або унікальним стовпчиком ключів в іншій таблиці. Індекс дозволяє Microsoft® SQL Server ™ 2000 швидко знаходити пов'язані дані в таблиці іноземних ключів. Однак створення цього індексу не є вимогою. Дані з двох пов’язаних таблиць можуть бути об'єднані, навіть якщо між таблицями не визначено обмежень PRIMARY KEY або FOREIGN KEY, але співвідношення зовнішнього ключа між двома таблицями вказує на те, що обидві таблиці були оптимізовані для об'єднання в запиті, який використовує ключі як її критерії.

Тож здається досить зрозумілим (хоча документація дещо заплутана), що насправді це не створює індекс.

Ні, немає неявного індексу на полях іноземних ключів, інакше чому Microsoft скаже «Створення індексу на зовнішньому ключі часто корисне» . Ваш колега може бути заплутаним ключове поле іноземного в посилається таблиці з первинним ключем в зазначених до таблиці - первинні ключі дійсно створити неявний індекс.

SQL Server автоматично створює індекси для первинних ключів, але не для іноземних ключів. Створіть індекс для іноземних ключів. Мабуть, варто накладні витрати.

Скажімо, у вас є велика таблиця, яка називається замовленнями, і маленька таблиця з назвою клієнтів. Існує іноземний ключ від замовлення до замовника. Тепер, якщо ви видалите клієнта, сервер Sql повинен перевірити, чи немає замовлень-сиріт; якщо є, це викликає помилку.

Щоб перевірити, чи є замовлення, сервер Sql повинен здійснити пошук у великій таблиці замовлень. Тепер, якщо є індекс, пошук буде швидким; якщо його немає, пошук буде повільним.

Тож у цьому випадку повільне видалення можна пояснити відсутністю індексу. Особливо, якщо сервер Sql повинен був шукати 15 великих таблиць без індексу.

PS Якщо в зовнішньому ключі є ВИКЛИКАТИ КАСКАД, Sql Server все ще повинен шукати таблицю замовлень, але потім видаляти будь-які замовлення, які посилаються на видаленого клієнта.

Іноземні ключі не створюють індексів. Тільки альтернативні обмеження ключів (UNIQUE) та обмеження первинного ключа створюють індекси. Це вірно в Oracle і SQL Server.

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

Строго кажучи, іноземні ключі абсолютно не мають нічого спільного з індексами, так. Але, як вказували динаміки вище мене, є сенс створити такий, щоб пришвидшити пошук у FK. Насправді, у MySQL, якщо ви не вказали індекс у своїй декларації FK, двигун (InnoDB) створює його автоматично для вас.

У PostgeSql ви можете перевірити наявність індексів, якщо ви натиснули \ d ім'я таблиці

Ви побачите, що btree-індекси створюються автоматично на стовпцях з первинним ключем та унікальними обмеженнями, але не на стовпцях із сторонніми ключами.

Я думаю, що це відповість на ваше запитання хоча б для постгресів.

Я зауважую, що Entity Framework 6.1, вказаний на MSSQL, автоматично додає індекси на зовнішні ключі.

InnoDB вимагає індексів на зовнішніх ключів і довідкових ключів , так що зовнішні ключі перевірки можуть бути швидко і не вимагає сканування таблиці. У таблиці посилань повинен бути індекс, де стовпці іноземного ключа вказані як перші стовпці в тому ж порядку.