Чи покращує зовнішній ключ ефективність запитів?

Припустимо, у мене є 2 таблиці, товари та категорії товарів. Обидві таблиці мають відношення до CategoryId. І це запит.

SELECT p.ProductId, p.Name, c.CategoryId, c.Name AS Category
FROM Products p
INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
WHERE c.CategoryId = 1;

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

Тому я повинен створити індекс на Products.CategoryId. Коли я знову створюю план виконання, обидві таблиці виконують пошук індексу. І орієнтовна вартість піддерев'я значно зменшується.

Мої запитання:

1. Окрім ФК допомагає у обмеженні стосунків, чи має вона якусь іншу корисність? Це покращує ефективність запитів?

2. Чи потрібно створити індекс у всіх стовпцях FK (сподобалось Products.CategoryId) у всіх таблицях?

Іноземні ключі - це референтний інструмент цілісності, а не інструмент продуктивності. Принаймні в SQL Server, створення FK не створює пов'язаний індекс, і ви повинні створювати індекси на всіх полях FK, щоб покращити час пошуку.

Іноземні ключі можуть покращити (і зашкодити) продуктивність

1. Як зазначено тут: Зовнішні ключі підвищують продуктивність

2. Ви завжди повинні створювати індекси на стовпцях FK, щоб зменшити кількість пошукових запитів. SQL Server не робить цього автоматично.

Редагувати

Оскільки тепер посилання здається мертвим (кудо, щоб Кріс помітив) , нижче показано суть того, чому іноземні клавіші можуть покращити (і нашкодити) продуктивності.

Чи може зовнішній ключ покращити ефективність

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

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

Іноземний ключ - це концепція СУБД для забезпечення цілісності бази даних.

Будь-які наслідки / покращення продуктивності будуть специфічними для використовуваної технології бази даних і є вторинними для цілей зовнішнього ключа.

Доброю практикою в SQL Server є забезпечення того, щоб усі зовнішні ключі мали принаймні некластеризований індекс на них.

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

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

Ви можете використовувати його, щоб зробити запит більш ефективним. Це дозволяє вам реструктуризувати запити в SQL Server, щоб використовувати зовнішнє з'єднання замість внутрішнього, яке видаляє сервери sql, необхідність перевіряти, чи немає у стовпці нуля. Вам не потрібно ставити цей кваліфікатор, оскільки зовнішні ключові відносини вже примушують це до вас.

Отже це:

    select p.ProductId, p.Name, c.CategoryId, c.Name AS Category 
from Products p inner join ProductCategories c on p.CategoryId = c.CategoryIdwhere c.CategoryId = 1;

Стає таким:

SELECT p.ProductId, p.Name, c.CategoryId, c.Name AS Category 
FROM ProductCategories c 
LEFT OUTER JOIN Products P ON
c.CategoryId = p.CategoryId 
WHERE c.CategoryId = 1;

Це не обов'язково забезпечує величезну ефективність у невеликих запитах, але коли таблиці набувають великих розмірів, це може бути ефективнішим.

Для MySQL 5.7 це, безумовно, може пришвидшити запити, що включають кілька приєднань напрочуд добре!

Я використав "пояснити", щоб зрозуміти свій запит, і виявив, що я приєднуюся до 4-5 таблиць - де жодні ключі не використовуються. Я нічого не робив, окрім як додав зовнішній ключ до цих таблиць, результатом було 90% скорочення часу завантаження. Запити, які брали> 5, зараз займають 500 мс або менше.

Це НЕОБХІДНЕ поліпшення!

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

Крім цього, забезпечення референтної цілісності має і власні переваги від продуктивності. Це має ефект другого порядку - гарантувати, що таблиці, які мають зовнішній ключ, "оновлені" з іноземною таблицею. Скажімо, у вас є таблиця користувачів та таблиця коментарів, і ви робите певну статистику в таблиці коментарів. Можливо, якщо ви важко видалите користувача, ви також не хочете їх коментарів.

Додавання іноземного ключа до таблиці не підвищить ефективність, просто кажучи, якщо ви вставляєте запис у базу даних таблиць ProductCategories, спробуєте знайти стовпчик іноземного ключа, який має значення, яке існує у первинному ключі таблиці таблиці продуктів. операція накладається на вашу базу даних щоразу, коли ви додаєте новий запис у таблицю ProductCategories. Таким чином, додаючи зовнішній ключ, це не покращить роботу вашої бази даних, але вона подбає про цілісність вашої бази даних. Так, це покращить продуктивність вашого db, якщо ви перевіряєте цілісність за допомогою зовнішнього ключа, замість того, щоб виконувати багато запитів для перевірки записів, що існують у базі даних вашої програми.

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

За станом на SQL Server 2008 зовнішні ключі можуть впливати на продуктивність, впливаючи на те, як движок бази даних вибирає оптимізацію запиту. Зверніться до евристики Star Join в наступній статті: https://technet.microsoft.com/en-us/library/2008.04.dwperformance.aspx