INNER JOIN - продуктивність LEFT JOIN у SQL Server

Я створив команду SQL, яка використовує INNER JOIN на 9 таблицях, у будь-якому випадку ця команда займає дуже багато часу (більше п'яти хвилин). Тож мій фольклор запропонував мені змінити INNER JOIN на LEFT JOIN, оскільки ефективність роботи LEFT JOIN краща, незважаючи на те, що я знаю. Після того як я змінив її, швидкість запиту значно покращилася.

Мені хотілося б дізнатися, чому СПІЛЬНЕ ПРИЄДНАННЯ швидше, ніж ВНУТРІШНЯ ПРИЄДНАЙТЕСЬ?

Моя команда SQL виглядає нижче: SELECT * FROM A INNER JOIN B ON ... INNER JOIN C ON ... INNER JOIN Dі так далі

Оновлення: Це коротка моя схема.

FROM sidisaleshdrmly a -- NOT HAVE PK AND FK
    INNER JOIN sidisalesdetmly b -- THIS TABLE ALSO HAVE NO PK AND FK
        ON a.CompanyCd = b.CompanyCd 
           AND a.SPRNo = b.SPRNo 
           AND a.SuffixNo = b.SuffixNo 
           AND a.dnno = b.dnno
    INNER JOIN exFSlipDet h -- PK = CompanyCd, FSlipNo, FSlipSuffix, FSlipLine
        ON a.CompanyCd = h.CompanyCd
           AND a.sprno = h.AcctSPRNo
    INNER JOIN exFSlipHdr c -- PK = CompanyCd, FSlipNo, FSlipSuffix
        ON c.CompanyCd = h.CompanyCd
           AND c.FSlipNo = h.FSlipNo 
           AND c.FSlipSuffix = h.FSlipSuffix 
    INNER JOIN coMappingExpParty d -- NO PK AND FK
        ON c.CompanyCd = d.CompanyCd
           AND c.CountryCd = d.CountryCd 
    INNER JOIN coProduct e -- PK = CompanyCd, ProductSalesCd
        ON b.CompanyCd = e.CompanyCd
           AND b.ProductSalesCd = e.ProductSalesCd 
    LEFT JOIN coUOM i -- PK = UOMId
        ON h.UOMId = i.UOMId 
    INNER JOIN coProductOldInformation j -- PK = CompanyCd, BFStatus, SpecCd
        ON a.CompanyCd = j.CompanyCd
            AND b.BFStatus = j.BFStatus
            AND b.ProductSalesCd = j.ProductSalesCd
    INNER JOIN coProductGroup1 g1 -- PK = CompanyCd, ProductCategoryCd, UsedDepartment, ProductGroup1Cd
        ON e.ProductGroup1Cd  = g1.ProductGroup1Cd
    INNER JOIN coProductGroup2 g2 -- PK = CompanyCd, ProductCategoryCd, UsedDepartment, ProductGroup2Cd
        ON e.ProductGroup1Cd  = g2.ProductGroup1Cd

A LEFT JOINабсолютно не швидше ніж INNER JOIN. Насправді це повільніше; за визначенням, зовнішнє з'єднання (LEFT JOIN або RIGHT JOIN) повинно виконувати всю роботу INNER JOINплюс додаткову роботу з розширенням нуля результатів. Очікується також повернути більше рядків, додатково збільшуючи загальний час виконання просто за рахунок збільшення розміру набору результатів.

(І навіть якщо a LEFT JOIN були швидшими в конкретних ситуаціях через якесь важко уявити злиття факторів, він функціонально не еквівалентний INNER JOIN, тому ви не можете просто замінити всі екземпляри одного іншим!)

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

Редагувати:

Розмірковуючи далі про це, я міг би подумати про одну обставину, за якої LEFT JOINможе бути швидше, ніж на INNER JOIN, і це коли:

• Деякі таблиці дуже маленькі (скажімо, під 10 рядів);
• У таблицях недостатньо індексів для покриття запиту.

Розглянемо цей приклад:

CREATE TABLE #Test1
(
    ID int NOT NULL PRIMARY KEY,
    Name varchar(50) NOT NULL
)
INSERT #Test1 (ID, Name) VALUES (1, 'One')
INSERT #Test1 (ID, Name) VALUES (2, 'Two')
INSERT #Test1 (ID, Name) VALUES (3, 'Three')
INSERT #Test1 (ID, Name) VALUES (4, 'Four')
INSERT #Test1 (ID, Name) VALUES (5, 'Five')

CREATE TABLE #Test2
(
    ID int NOT NULL PRIMARY KEY,
    Name varchar(50) NOT NULL
)
INSERT #Test2 (ID, Name) VALUES (1, 'One')
INSERT #Test2 (ID, Name) VALUES (2, 'Two')
INSERT #Test2 (ID, Name) VALUES (3, 'Three')
INSERT #Test2 (ID, Name) VALUES (4, 'Four')
INSERT #Test2 (ID, Name) VALUES (5, 'Five')

SELECT *
FROM #Test1 t1
INNER JOIN #Test2 t2
ON t2.Name = t1.Name

SELECT *
FROM #Test1 t1
LEFT JOIN #Test2 t2
ON t2.Name = t1.Name

DROP TABLE #Test1
DROP TABLE #Test2

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

Ви можете побачити той же ефект, написавши програму улюбленою мовою програмування для виконання великої кількості пошукових запитів у списку з 5 елементами, порівняно з хеш-таблицею з 5 елементами. Через розмір версія хеш-таблиці насправді повільніше. Але збільште його до 50 елементів, або 5000 елементів, і версія списку сповільнюється до сканування, оскільки це хештелі O (N) проти O (1).

Але змініть цей запит, щоб він був у IDстовпці, а Nameви побачите зовсім іншу історію. У цьому випадку вона робить вкладені петлі для обох запитів, але INNER JOINверсія здатна замінити одне кластеризоване сканування індексу на пошук - це означає, що це буде буквально на порядок швидше з великою кількістю рядків.

Тож висновок є більш-менш тим, що я згадав кілька абзаців вище; це майже напевно проблема індексації чи покриття індексу, можливо, поєднана з однією або кількома дуже маленькими таблицями. Це єдині обставини, за яких SQL Server іноді може вибрати гірший план виконання для, INNER JOINніж a LEFT JOIN.

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

При використанні зовнішнього з'єднання оптимізатор завжди може скинути зовнішню з'єднану таблицю з плану виконання, якщо стовпці з'єднання є ПК зовнішньої таблиці, і жоден із стовпців зовнішньої таблиці не посилається поза самим зовнішнім з'єднанням. Наприклад, SELECT A.* FROM A LEFT OUTER JOIN B ON A.KEY=B.KEYі B.KEY - це ПК для B. І Oracle (я вважаю, я використовував випуск 10), і Sql Server (я використав 2008 R2) обріжте таблицю B з плану виконання.

Це не обов'язково стосується внутрішнього з'єднання: SELECT A.* FROM A INNER JOIN B ON A.KEY=B.KEYможе або не вимагає B у плані виконання залежно від того, які обмеження існують.

Якщо A.KEY є нульовим зовнішнім ключем, що посилається на B.KEY, оптимізатор не може скинути B з плану, оскільки він повинен підтвердити, що B рядок існує для кожного рядка A.

Якщо A.KEY є обов'язковим зовнішнім ключем, що посилається на B.KEY, оптимізатор може скинути B з плану, оскільки обмеження гарантують існування рядка. Але те, що оптимізатор може скинути таблицю з плану, не означає, що це буде. SQL Server 2008 R2 НЕ скидає B із плану. Oracle 10 НЕ скидає B з плану. Неважко зрозуміти, як зовнішнє з'єднання буде виконувати внутрішнє з'єднання на SQL Server у цьому випадку.

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

Але це може бути дуже важливим дизайном при розгляді проекту. Часто створюється перегляд "робити все", який поєднує все, що може знадобитися користувачеві, пов'язане з центральною таблицею. (Особливо, якщо є наївні користувачі, які виконують спеціальні запити, які не розуміють реляційну модель). Перегляд може містити всі необхідні стовпці з багатьох таблиць. Але кінцеві користувачі можуть отримувати доступ до стовпців лише з підмножини таблиць у представленні. Якщо таблиці з'єднані із зовнішніми об'єднаннями, оптимізатор може (і робить) викинути непотрібні таблиці з плану.

Вкрай важливо переконатися, що вид з використанням зовнішніх з'єднань дає правильні результати. Як сказав Aaronaught - ви не можете сліпо підміняти ВНУТРІШНЕ ПРИЄДНАННЯ на ВНУТРІШНЕ ПРИЄДНАННЯ і очікувати тих же результатів. Але бувають випадки, коли це може бути корисно з міркувань продуктивності при використанні представлень.

Останнє зауваження - я не перевіряв вплив на продуктивність у світлі вищевикладеного, але теоретично, здається, ви повинні бути в змозі безпечно замінити ВНУТРІШНЕ ПРИЄДНАННЯ НА ЗОВНІШНІ ПРИЄДНАННЯ, якщо ви також додасте умову <FOREIGN_KEY> НЕ НУЛЬНО до пункту де

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

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

Я переживав деякі випадки, коли ліве з'єднання було швидше, ніж внутрішнє з'єднання.

Основна причина така: Якщо у вас дві таблиці, і ви приєднуєтесь до стовпця з індексом (в обох таблицях). Внутрішнє з'єднання дасть той самий результат, незалежно від того, якщо ви переведіть на записи в індексі таблиці 1 та збігаєтеся з індексом на таблиці 2 так, як якщо б ви зробили зворотний: переведіть на записи в індексі таблиці 2 та збігайтесь з індексом в таблиці перша. Проблема полягає в тому, що у вас є оманлива статистика, оптимізатор запитів використовуватиме статистику індексу для пошуку таблиці з найменшими відповідніми записами (виходячи з інших ваших критеріїв). Якщо у вас дві таблиці, по 1 мільйон у кожній, у першій таблиці 10 збігів рядків, а у другій таблиці - 100000 рядків. Найкращим способом було б провести сканування індексу на першій таблиці та зіставити 10 разів у таблиці дві. Зворотним було б індексне сканування, яке містить цикл понад 100000 рядків і намагається відповідати 100000 разів, і лише 10 досягають успіху. Тож якщо статистика не є правильною, оптимізатор може вибрати неправильну таблицю та індекс, щоб перейти на цикл.

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

АЛЕ, оптимізатор може також оптимізувати ліве з'єднання під оптимальним варіантом як ліве напівприєднання. Щоб вибрати, який ви хочете, ви можете скористатись підказом про примусовий наказ.

Спробуйте обидва запити (той, що має внутрішній і лівий приєднання), OPTION (FORCE ORDER)в кінці та опублікуйте результати. OPTION (FORCE ORDER)- це підказка запиту, яка змушує оптимізатора будувати план виконання з порядком приєднання, який ви вказали в запиті.

Якщо INNER JOINпочне виконувати так швидко LEFT JOIN, це тому, що:

• У запиті, повністю складеному користувачем INNER JOIN s, порядок з'єднання не має значення. Це дає свободу оптимізатору запитів замовляти приєднання так, як він вважає за потрібне, тому проблема може покладатися на оптимізатор.
• З LEFT JOIN, це не так, оскільки зміна порядку з'єднання змінить результати запиту. Це означає, що двигун повинен виконувати порядок з'єднання, який ви вказали у запиті, що може бути краще, ніж оптимізоване.

Не знаю, чи відповідає це на ваше запитання, але я колись був у проекті, в якому були дуже складні запити, які робили розрахунки, які повністю заплутали оптимізатор. У нас були випадки, коли a FORCE ORDERзменшив час виконання запиту з 5 хвилин до 10 секунд.

Зробив ряд порівнянь між лівим зовнішнім і внутрішнім з'єднанням і не зміг знайти стійку різницю. Існує багато змінних. Я працюю над базою звітів з тисячами таблиць, багато з великою кількістю полів, багато змін з часом (версії постачальників та локальний робочий процес). Неможливо створити всі комбінації покриття індексів для задоволення потреб такого широкого спектру запитів та обробки історичних даних. Побачили, що внутрішні запити вбивають продуктивність сервера, тому що дві великі (мільйони до десятків мільйонів рядків) таблиці є внутрішніми об'єднаними обома, що тягнуть велику кількість полів, а індекс покриття не існує.

Однак, найбільше питання, схоже, не виникає в обговоренні вище. Можливо, ваша база даних добре розроблена з тригерами та добре продуманою обробкою транзакцій для забезпечення хороших даних. У шахти часто є значення NULL там, де їх не очікується. Так, визначення таблиць можуть примусово застосовувати no-Nulls, але це не є варіантом у моєму середовищі.

Тож питання полягає в тому, чи ви розробляєте запит лише на швидкість, що є більш високим пріоритетом для обробки транзакцій, яка виконує один і той же код тисячі разів на хвилину. Або ви шукаєте точність, яку забезпечить лівий зовнішній з’єднання. Пам'ятайте, що внутрішні з'єднання повинні знаходити збіги з обох сторін, тому несподіваний NULL не буде видаляти дані з двох таблиць, але, можливо, цілі рядки інформації. І це буває так приємно, жодних повідомлень про помилки.

Ви можете бути дуже швидкими, оскільки отримуєте 90% необхідних даних і не виявляєте внутрішні приєднання, мовчки видаливши інформацію. Іноді внутрішні приєднання можуть бути швидшими, але я не вірю, що хтось зробив це припущення, якщо не переглянув план виконання. Швидкість важлива, але важливіша точність.

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

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

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

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

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

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

Джерело: http://www.sqlservercentral.com/blogs/sql_coach/2010/07/29/poor-little-misunderposed-views/

Я виявив щось цікаве на SQL сервері, коли перевіряв, чи внутрішні з'єднання швидші, ніж ліві з'єднання.

Якщо ви не включаєте елементи лівої об’єднаної таблиці, у операторі select ліве з'єднання буде швидше, ніж той самий запит із внутрішнім об'єднанням.

Якщо ви включите ліву об'єднану таблицю в оператор select, внутрішнє з'єднання з тим же запитом було рівним або швидшим, ніж ліве з'єднання.

Зі своїх порівнянь я виявляю, що вони мають точно такий же план виконання. Існує три сценарії:

1. Якщо і коли вони повертають однакові результати, вони мають однакову швидкість. Однак ми маємо пам’ятати, що це не ті самі запити, і що LEFT JOIN, можливо, поверне більше результатів (коли деякі умови ON не будуть дотримані) --- тому це зазвичай повільніше.

2. Коли основна таблиця (перша, що не стосується const в плані виконання) має обмежувальну умову (WHERE id =?) І відповідна умова ON на значення NULL, "правильна" таблиця не приєднується --- це коли ЛІВО ПРИЄДНАЙТЕСЬ швидше.

3. Як обговорюється в пункті 1, зазвичай ВНУТРІШНЕ ПРИЄДНАННЯ є більш обмежувальним і дає менше результатів і, отже, швидше.

Обидва використовують (однакові) індекси.