Почему LIKE будет быстрее, чем =?

Сотрудник недавно столкнулся с ситуацией, когда запрос на поиск разрешений безопасности выполнялся примерно через 15 секунд с использованием сравнения = с идентификатором пользователя (который является UNIQUEIDENTIFIER). Излишне говорить, что пользователи были менее чем впечатлены.

Из-за разочарования мой коллега изменил сравнение =, чтобы использовать НРАВИТСЯ, и запрос ускорился менее чем до 1 секунды.

Ничего не зная о схеме данных (у меня нет доступа к базе данных или планам выполнения), что потенциально может вызвать такое изменение производительности?

(Обширный и расплывчатый вопрос, я знаю)


database sql-server tsql sql-server-2005
person Jeremiah Peschka    schedule 05.11.2008    source источник
comment
Вы ответили своему коллеге с этими предложениями?   -  person Mike Burton    schedule 06.11.2008
comment
Я еще не получил, я только что получил копию планов казни и буду просматривать их в эти выходные. Я передам предложения и опубликую любые отзывы, которые я получу от моего коллеги.   -  person Jeremiah Peschka    schedule 07.11.2008

Ответы (5)


arrow_upward
8
arrow_downward

Возможно, это был просто неудачный план выполнения, который был закэширован; Переход к оператору LIKE только что вызвал создание нового плана выполнения. Такое же ускорение можно было бы заметить, если бы человек запустил процедуру sp_recompile для рассматриваемой таблицы, а затем повторно запустил запрос =.

person Chris Shaffer    schedule 05.11.2008

arrow_upward
8
arrow_downward

Другая возможность заключается в том, что это сложный запрос, и преобразование типов происходит через оператор = для каждой строки. LIKE несколько изменяет семантику, так что преобразование типов не должно иметь такого большого веса при планировании выполнения. Я бы посоветовал вашему коллеге взглянуть на план выполнения с установленным = и посмотреть, есть ли что-то вроде

CONVERT(varchar, variable) = othervariable

на этапе выполнения. В неподходящих обстоятельствах одно приведение типа может замедлить выполнение запроса на два порядка.

person Mike Burton    schedule 05.11.2008
comment
Это вполне может быть так, PK является UNIQUEIDENTIFIER, поэтому может происходить какое-то странное преобразование VARCHAR ‹-› GUID. - person Jeremiah Peschka; 05.11.2008

arrow_upward
1
arrow_downward

В некоторых случаях LIKE может быть быстрее эквивалентной функции, такой как SUBSTRING, когда можно использовать индекс.

Можете ли вы дать точное SQL?

Иногда функции могут помешать оптимизатору использовать индекс.

Сравните планы выполнения.

person Cade Roux    schedule 05.11.2008

arrow_upward
1
arrow_downward

Ну, а если он выполнял два запроса один за другим, то вполне вероятно, что для первого запроса данные должны были быть прочитаны с диска, а для второго все еще находились в кеше данных СУБД...

Если это то, что произошло, то если бы он выполнил их в обратном порядке, он бы увидел противоположные результаты... Если бы он использовал как с точным значением (без подстановочных знаков), то план запроса должен был быть идентичным..

person Charles Bretana    schedule 05.11.2008

arrow_upward
0
arrow_downward

Вы пытались обновить статистику в этой таблице/базе данных? Может стоит попробовать.

person Lasse V. Karlsen    schedule 05.11.2008