SQL 'як' проти '=' продуктивність

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

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

select * from table where value like 'abc%'

і

select * from table where value = 'abcdefghijklmn'

"Подобається" потрібно лише протестувати перші три символи, щоб знайти відповідність, тоді як "=" має порівняти весь рядок. У цьому випадку мені здається, що "подобається" матиме перевагу за інших рівних умов.

Це задумано як загальне, академічне питання, і тому не має значення, яка БД, але воно виникло за допомогою SQL Server 2005.

Див. Https://web.archive.org/web/20150209022016/http://myitforum.com/cs2/blogs/jnelson/archive/2007/11/16/108354.aspx

Цитата звідти:

правила використання індексу з LIKE такі:

• Якщо у ваших критеріях фільтра використовується дорівнює = і поле індексується, то, швидше за все, воно буде використовувати ІНДЕКС / КЛАСТЕРОВАНИЙ ІНДЕКС ШУК

• Якщо у ваших критеріях фільтра використовується LIKE, без підстановочних знаків (наприклад, якщо у вас у веб-звіті був параметр, МОЖИЙ мати%, але замість цього ви використовуєте повний рядок), це приблизно так само, як # 1, використовувати індекс. Збільшена вартість - майже нічого.

• Якщо у ваших критеріях фільтра використовується LIKE, але з підстановкою на початку (як у Name0 LIKE '% UTER'), набагато менше шансів використовувати індекс, але він все одно може принаймні виконати INDEX SCAN на повному або частковому діапазоні індекс.

• Втім, якщо ваш критерій фільтра використовує LIKE, але починається з STRING FIRST і має де-небудь символи підстановки ПІСЛЯ цього (як у Name0 LIKE 'COMP% ER'), тоді SQL може просто використовувати INDEX SEEK для швидкого пошуку рядків, які мають однакові перші початкові символи, а потім перегляньте ці рядки для точного збігу.

(Також майте на увазі, механізм SQL все одно може використовувати індекс не так, як ви очікуєте, залежно від того, що ще відбувається у вашому запиті та до яких таблиць ви приєднуєтеся. Механізм SQL залишає за собою право переписати ваші запитайте трохи, щоб отримати дані таким чином, який, на його думку, є найбільш ефективним, і який може включати ІНДЕКС-СКАН замість ІНДЕКС-ШУКУ)

Це помітна різниця.

Запустіть наступне:

Create Table #TempTester (id int, col1 varchar(20), value varchar(20))
go

INSERT INTO #TempTester (id, col1, value)
VALUES
(1, 'this is #1', 'abcdefghij')
GO

INSERT INTO #TempTester (id, col1, value)
VALUES
(2, 'this is #2', 'foob'),
(3, 'this is #3', 'abdefghic'),
(4, 'this is #4', 'other'),
(5, 'this is #5', 'zyx'),
(6, 'this is #6', 'zyx'),
(7, 'this is #7', 'zyx'),
(8, 'this is #8', 'klm'),
(9, 'this is #9', 'klm'),
(10, 'this is #10', 'zyx')
GO 10000

CREATE CLUSTERED INDEX ixId ON #TempTester(id)CREATE CLUSTERED INDEX ixId ON #TempTester(id)

CREATE NONCLUSTERED INDEX ixTesting ON #TempTester(value)

Тоді:

SET SHOWPLAN_XML ON

Тоді:

SELECT * FROM #TempTester WHERE value LIKE 'abc%'

SELECT * FROM #TempTester WHERE value = 'abcdefghij'

Отриманий план виконання показує, що вартість першої операції, LIKEпорівняння, приблизно в 10 разів дорожча =порівняння.

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

Ви також повинні пам’ятати, що під час використання likeдеякі варіанти sql ігноруватимуть індекси, що призведе до зниження продуктивності. Це особливо вірно, якщо ви не використовуєте шаблон "починається з", як ваш приклад.

Ви повинні реально поглянути на план виконання запиту і побачити, що він робить, гадати якомога менше.

Сказано, шаблон "починається з" може і оптимізується на сервері sql. Він буде використовувати індекс таблиці. EF 4,0 перемикається likeна StartsWithз цієї причини.

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

Якщо valueіндексується, як зазначає Даніель у своєму коментарі, =результат призведе до пошуку індексу, що є продуктивністю O (log N). ЯК буде (швидше за все - в залежності від того, як воно селективного) в результаті часткового сканування індексу >= 'abc'і < 'abd'який зажадає більше зусиль , ніж =.

Зверніть увагу, що тут я говорю про SQL Server - не всі СУБД будуть приємні з LIKE.

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

Отже, як LIKEі =порівняти з точки зору SARGability? LIKE, коли використовується з виразом, який не починається з константи (наприклад, коли використовується LIKE '%something'), за визначенням не є SARGabale. Але це робить =або LIKE 'something%'SARGable? Ні. Як і на будь-яке запитання щодо продуктивності SQL, відповідь не на запит тексту, а на розгорнуту схему. Ці вирази можуть бути SARGable, якщо для їх задоволення існує індекс.

Отже, по правді кажучи, між =і є невеликі відмінності LIKE. Але запитати, чи є один оператор чи інший оператор „швидшим” у SQL, все одно, що запитати „Що йде швидше, червона машина чи синя машина?”. Ви повинні задавати питання про розмір двигуна та вагу транспортного засобу, а не про колір ... Щоб підійти до питань щодо оптимізації реляційних таблиць, слід шукати свої індекси та вирази в реченні WHERE (та інших реченнях, але це зазвичай починається з ДЕ).

Особистий приклад використання mysql 5.5: У мене було внутрішнє з'єднання між 2 таблицями, однією з 3 мільйонів рядків і однією з 10 тисяч рядків.

При використанні подібного для індексу, як показано нижче (без підстановочних знаків), це зайняло близько 30 секунд:

where login like '12345678'

за допомогою "пояснити" я отримую:

При використанні '=' для того самого запиту, це зайняло близько 0,1 секунди:

where login ='600009'

Використовуючи "пояснити", я отримую:

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

Можливо, ви шукаєте повнотекстовий пошук .

На відміну від повнотекстового пошуку, предикат LIKE Transact-SQL працює лише на шаблонах символів. Крім того, ви не можете використовувати предикат LIKE для запиту відформатованих двійкових даних. Крім того, запит LIKE щодо великої кількості неструктурованих текстових даних набагато повільніший, ніж еквівалентний повнотекстовий запит щодо тих самих даних . Повторний запит щодо мільйонів рядків текстових даних може повернутися за хвилини; тоді як повнотекстовий запит може зайняти лише кілька секунд або менше щодо тих самих даних, залежно від кількості рядків, які повертаються.

Насамперед ,

вони не завжди рівні

    select 'Hello' from dual where 'Hello  ' like 'Hello';

    select 'Hello' from dual where 'Hello  ' =  'Hello';

коли речі не завжди рівні, говорити про їх ефективність не так актуально.

Якщо ви працюєте над рядками та лише змінними char, тоді ви можете говорити про продуктивність. Але не використовуйте like і "=" як загальнозамінні.

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