Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
Доброго времени суток.

Почему like в строке, состоящей из чисел работает медленнее, чем like в буквенной строке?
Пример:
create table t (
                     id int identity(1,1), 
                     num varchar(10),  --состоит только из цифр
                     f varchar(30), --f/i/o - состоят только из букв
                     i varchar(30), 
                     o varchar(30)
                    )
select top 2000 id
from t --В t около 8 млн. записей
where num like '%123456%' --найдено 18 записей за 7 секунд

select top 2000 id
from t
where f + i + o like '%иванов%' --найдено 2000 записей за 150-200 милисекунд


В таблице около 8 млн. записей, в 1м и во 2м примерах используются индексы (в первом индекс num, во втором, соответственно f,i,o).
При этом - поиск в f + i + o выполняется за 150-200 мсек при любой длине строки поиска, а поиск в num - чем больше длина искомого фрагмента, тем больше время выполнения=(
14 авг 14, 16:48    [16442494]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
SQLBeginner2014
В таблице около 8 млн. записей, в 1м и во 2м примерах используются индексы (в первом индекс num, во втором, соответственно f,i,o).
Это вы так план пересказываете?
14 авг 14, 16:51    [16442504]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
iap
Member

Откуда: Москва
Сообщений: 47001
SQLBeginner2014,

индексы не используются в этих примерах совсем.
Про них и говорить не стоит
14 авг 14, 16:53    [16442513]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Офисный Хомячок
Member

Откуда: Офис
Сообщений: 1358
Индексы одинаково фрагментированны и перемешанны?

Индексы лучше работают при выборке большого количества строк
14 авг 14, 16:53    [16442519]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
iap
Member

Откуда: Москва
Сообщений: 47001
Офисный Хомячок
Индексы одинаково фрагментированны и перемешанны?

Индексы лучше работают при выборке большого количества строк
Какие тут индекы?
В первом случае '%...%', во втором - условие для суммы полей и плюс ещё то же, что и в первом.
14 авг 14, 16:57    [16442537]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Офисный Хомячок
Member

Откуда: Офис
Сообщений: 1358
iap
Офисный Хомячок
Индексы одинаково фрагментированны и перемешанны?

Индексы лучше работают при выборке большого количества строк
Какие тут индекы?
В первом случае '%...%', во втором - условие для суммы полей и плюс ещё то же, что и в первом.


Каюсь, я скрипт не смотрел:-(
14 авг 14, 17:00    [16442549]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
set statistics time on;
select top 2000 ID from t where Num like '%564584%'
set statistics time off;

(строк обработано: 18)

 Время работы SQL Server:
   Время ЦП = 7472 мс, затраченное время = 7493 мс.


set statistics time on;
select top 2000 ID from t where f+i+o like '%семен%'
set statistics time off;

(строк обработано: 2000)

 Время работы SQL Server:
   Время ЦП = 78 мс, затраченное время = 166 мс.


iap
SQLBeginner2014,

индексы не используются в этих примерах совсем.
Про них и говорить не стоит


тогда почему без индексов эти запросы выполняются дай бог по минуте каждый?
14 авг 14, 17:11    [16442583]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Офисный Хомячок
Member

Откуда: Офис
Сообщений: 1358
SQLBeginner2014
set statistics time on;
select top 2000 ID from t where Num like '%564584%'
set statistics time off;

(строк обработано: 18)

 Время работы SQL Server:
   Время ЦП = 7472 мс, затраченное время = 7493 мс.


set statistics time on;
select top 2000 ID from t where f+i+o like '%семен%'
set statistics time off;

(строк обработано: 2000)

 Время работы SQL Server:
   Время ЦП = 78 мс, затраченное время = 166 мс.


iap
SQLBeginner2014,

индексы не используются в этих примерах совсем.
Про них и говорить не стоит


тогда почему без индексов эти запросы выполняются дай бог по минуте каждый?


"Имя, сестра, имя!"©

Гораздо легче с вами было бы говорить, если бы вы потрудились привести планы выполнения запросов.
14 авг 14, 17:18    [16442610]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
iap
Member

Откуда: Москва
Сообщений: 47001
SQLBeginner2014,

строк с искомой числовой строкой - всего 18.
Значит, пришлось сканировать всю таблицу, чтобы их набрать.
Строк с 'ивановым' намного больше 2000, и эти первые 2000 набрались в самом начале сканирования,
после чего сервер бросил это дело и выдал результат.
14 авг 14, 17:18    [16442614]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
iap,

а можно как-то ускорить этот процесс? может не like использовать, а что-то другое?
Попробовал поставить вот такое условие:
select id
from t
where exists(select id from t as t1 where t1.id = t.id and t1.num like '%123456%')

Получилось немного быстрее
(строк обработано: 18)

 Время работы SQL Server:
   Время ЦП = 7252 мс, затраченное время = 7261 мс.
14 авг 14, 17:37    [16442767]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
iap
SQLBeginner2014,

строк с искомой числовой строкой - всего 18.
Значит, пришлось сканировать всю таблицу, чтобы их набрать.
Строк с 'ивановым' намного больше 2000, и эти первые 2000 набрались в самом начале сканирования,
после чего сервер бросил это дело и выдал результат.


Решил проверить:

select top 2000 id
from t
where f + i + o like '%евген%'

(строк обработано: 17)

 Время работы SQL Server:
   Время ЦП = 234 мс, затраченное время = 261 мс.
14 авг 14, 17:45    [16442833]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
SQLBeginner2014,

зависит от порога стоимости параллелизма. Смотрите план выполнения и не морочьте людям голову
14 авг 14, 17:49    [16442857]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
iap
строк с искомой числовой строкой - всего 18.
Значит, пришлось сканировать всю таблицу, чтобы их набрать.
Строк с 'ивановым' намного больше 2000, и эти первые 2000 набрались в самом начале сканирования,
после чего сервер бросил это дело и выдал результат.

почему-то скулю все равно сколько искомых числовых строк у меня в таблице - хоть 18, хоть 2 млн. - он равно выводит их за ~7 сек, а буквенные - будь их хоть 18 записей, хоть так же пара-тройка млн. - пролетает за пару сотен мс.
Владислав Колосов
зависит от порога стоимости параллелизма

Я в курсе, что при одновременном запросе данных несколькими пользователя время отработки увеличивается, и на момент выполнения запросов никто ничего не делал в БД, кроме меня.
Владислав Колосов
не морочьте людям голову

Мне не интересно никому и ничего морочить. Сейчас мне интересно - почему поиск в строке из чисел проходит медленнее, чем в строке буквенной. И написал не для того, чтобы, конечно же, бредом отвлекать умных и, конечно же, занятых людей, а чтобы понять - может у кого что-то подобное было, может не знаю я чего, может в скуле что-то, может есть другие варианты поиска в числовой строе - в общем узнать что-то полезное.
15 авг 14, 09:45    [16444459]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Мы план запросов когда-нибудь увидим? Или, хотя бы, статистику выполнения? Или будем продолжать из пустого в порожнее переливать?

Сообщение было отредактировано: 15 авг 14, 10:01
15 авг 14, 09:58    [16444508]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
План приложен

К сообщению приложен файл. Размер - 32Kb
15 авг 14, 10:14    [16444579]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
aleks2
Guest
iap
SQLBeginner2014,

индексы не используются в этих примерах совсем.
Про них и говорить не стоит


Ты не прав, Брут.
Сервер может сканировать индексы и это будет быстрее, если индекс уже кластерного.
15 авг 14, 10:15    [16444581]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Konst_One
Member

Откуда:
Сообщений: 11540
select top 2000 ID from t where Num like '%5%'


а теперь вот такой выполните и удивитесь
15 авг 14, 10:16    [16444587]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
SQLBeginner2014
Member

Откуда:
Сообщений: 31
Konst_One
select top 2000 ID from t where Num like '%5%'


а теперь вот такой выполните и удивитесь


SQLBeginner2014
поиск в num - чем больше длина искомого фрагмента, тем больше время выполнения
- первый пост.
15 авг 14, 10:22    [16444626]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
aleks2
Guest
SQLBeginner2014
План приложен


Странно,
set statistics time on
освоил, а
set showplan_text on
нет.
15 авг 14, 10:23    [16444633]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
top 2000 убрите, и выяснится, что работает одинаково.
15 авг 14, 10:24    [16444635]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
aleks2
Guest
SQLBeginner2014
Доброго времени суток.

Почему like в строке, состоящей из чисел работает медленнее, чем like в буквенной строке?
Пример:
create table t (
                     id int identity(1,1), 
                     num varchar(10),  --состоит только из цифр
                     f varchar(30), --f/i/o - состоят только из букв
                     i varchar(30), 
                     o varchar(30)
                    )
select top 2000 id
from t --В t около 8 млн. записей
where num like '%123456%' --найдено 18 записей за 7 секунд

select top 2000 id
from t
where f + i + o like '%иванов%' --найдено 2000 записей за 150-200 милисекунд


В таблице около 8 млн. записей, в 1м и во 2м примерах используются индексы (в первом индекс num, во втором, соответственно f,i,o).
При этом - поиск в f + i + o выполняется за 150-200 мсек при любой длине строки поиска, а поиск в num - чем больше длина искомого фрагмента, тем больше время выполнения=(


Осподе милосердный, TOP 2000 вовсе не означает "просмотреть 2000 записей" и фсе.
Сервер может найти в первых строках таблицы, а может колбасить всю таблицу.
И количество этих "обрабатываемых строк" зависит от условия запроса.
15 авг 14, 10:27    [16444650]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31443
SQLBeginner2014
почему-то скулю все равно сколько искомых числовых строк у меня в таблице - хоть 18, хоть 2 млн. - он равно выводит их за ~7 сек, а буквенные - будь их хоть 18 записей, хоть так же пара-тройка млн. - пролетает за пару сотен мс.
Этого мы не видим, в ваших примерах этого нет.

Пока что всё прозрачно - в первом запросе серверу пришлось просканировать всю таблицу, что бы получить 18 записей, а во втором он просканировал совсем немного страниц, что бы получить искомые 2000 записей.

Никакой мистики.
15 авг 14, 10:40    [16444753]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
ЕвгенийВ
Member

Откуда: Москва
Сообщений: 4951
SQLBeginner2014
where f + i + o like '%иванов%' --найдено 2000 записей за 150-200 милисекунд


Если в одном из полей будет "иванов", а любое другое будет null - не найдет.
15 авг 14, 10:48    [16444836]     Ответить | Цитировать Сообщить модератору
 Re: Like  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Это не план запроса, это картинка плана.
15 авг 14, 11:27    [16445132]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить