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

Откуда:
Сообщений: 71
Имею некую таблицу (id INT, .... data TEXT)
Индексирую по id

Выполняю запрос:
SELECT * FROM t WHERE id=1
выполнено за 10 сек и возвращено 2000 записей

А такой запрос:
SELECT * FROM t WHERE id=1 AND datalength(data)>0
выполнено за 15 сек и возвращено 1000 записей

По логике вещей запрос 2 не может выполнять медленнее первого, т.к. во первых сама проверка времени не занимает и значение считывать с диска доп. не нужно, т.к. оно уже передается через SELECT *, да и результирующий SET в запросе 2 меньше.

Почему так происходит?
13 фев 12, 13:10    [12081006]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
По логике вещей запрос 2 не может выполнять медленнее первого, т.к. во первых сама проверка времени не занимает и значение считывать с диска доп. не нужно

Вот вы и сравните вашу логику с логикой сервера. Через просмотр плана выполнения
Он вам и покажет, что, когда и сколько читается
13 фев 12, 13:12    [12081016]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
это как, можно подробнее?
13 фев 12, 13:13    [12081033]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
это как, можно подробнее?

Что именно "как" ? Как получить план выполнения ? Нажать в SMS соответствующую кнопочку в меню
13 фев 12, 13:14    [12081044]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
использую Express
а вообще такое являние можно как-то аналитически объяснить? это неоптимальность сервера или где?
13 фев 12, 13:16    [12081059]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
victorovich
использую Express
а вообще такое являние можно как-то аналитически объяснить? это неоптимальность сервера или где?
Кофе закончился, на гуще не погадать. Давайте планы уже.
13 фев 12, 13:17    [12081070]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
а вообще такое являние можно как-то аналитически объяснить?

Способов выполнения такого запроса существует больше, чем один
13 фев 12, 13:18    [12081082]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
LSV
Member [заблокирован]

Откуда: Киев
Сообщений: 30817
автор
По логике вещей запрос 2 не может выполнять медленнее первого
Экая чушь. Как видите, может. И правильно делает. Подсчет размера БЛОБ-поля видимо небыстрая процедура.
13 фев 12, 13:34    [12081221]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
_djХомяГ
Guest
плюс обращение к доп полю data (если оно также не входит в индекс) может запросто вызвать доп операции чтения
13 фев 12, 13:38    [12081239]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
_djХомяГ
Guest
пред сообщение верно, если индекс по id некластерный
13 фев 12, 13:39    [12081249]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а выполните еще вот так:

SELECT * , datalength(data) FROM t WHERE id=1


это будет более честно :)
13 фев 12, 13:43    [12081288]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
Crimean
SELECT * , datalength(data) FROM t WHERE id=1


Хитрый путь. Проверил. datalength(data) в select вообще не повлияло на скорость, причем независимо от наличия его в WHERE!

LSV
Подсчет размера БЛОБ-поля видимо небыстрая процедура


как видите, моментальная!

djХомяГ
плюс обращение к доп полю data (если оно также не входит в индекс) может запросто вызвать доп операции чтения


Не может, т.к. эт ополе уже передается в результирующий set. Это если бы вместо select * у меня бы был select id, то тут вы правы.



Так что вопрос открыт по-прежнему.
13 фев 12, 14:00    [12081442]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
Так что вопрос открыт по-прежнему.

Вы хотите, чтобы кто-то за вас получил план выполнения ваших запросов ? И статистику чтений ?
И рассказал вам, в чем их отличие ?
13 фев 12, 14:05    [12081484]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
Хитрый путь. Проверил. datalength(data) в select вообще не повлияло на скорость

Интересно, а вы как собстенно скорость то меряете ?
13 фев 12, 14:06    [12081490]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
_djХомяГ
Guest
Не может, т.к. эт ополе уже передается в результирующий set. Это если бы вместо select * у меня бы был select id, то тут вы правы.


Не оч понял - т е вы хотите сказать, что сервер на должен "оценить" значение поля ("обратиться к полю") если оно стоит в условии WHERE?
Смотрите планы
13 фев 12, 14:08    [12081506]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
Glory
victorovich
Хитрый путь. Проверил. datalength(data) в select вообще не повлияло на скорость

Интересно, а вы как собстенно скорость то меряете ?


На песочные часы смотрю :)
13 фев 12, 14:14    [12081560]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
На песочные часы смотрю :)

Оно и заметно.
13 фев 12, 14:15    [12081567]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
_djХомяГ
Не может, т.к. эт ополе уже передается в результирующий set. Это если бы вместо select * у меня бы был select id, то тут вы правы.


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


Очевидно причина тут одна:
если я указал серверу проверять сначала id=1, а только потом datalength()>0 , то он иногда (вопрос-когда?) проверяет сначала datalength()>0
другого здесь быть не может ничего
13 фев 12, 14:16    [12081582]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
сейчас попробовал поменять местами :
WHERE datalength(text)>0 AND id=1
тоже самое

может есть какой-то способ указать серверу, как именно вести проверку условий
я то думал, что если условие "И", то второе не проверяется если не выполнено первое
13 фев 12, 14:19    [12081607]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
victorovich
сейчас попробовал поменять местами :
WHERE datalength(text)>0 AND id=1
тоже самое

может есть какой-то способ указать серверу, как именно вести проверку условий
я то думал, что если условие "И", то второе не проверяется если не выполнено первое
Вы нам план сегодня покажете? Или дальше "думать" будете?
13 фев 12, 14:21    [12081622]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
Очевидно причина тут одна:
если я указал серверу проверять сначала id=1, а только потом datalength()>0 , то он иногда (вопрос-когда?) проверяет сначала datalength()>0
другого здесь быть не может ничего

Вот сразу видно хорошего специалиста.
Время замеряет по песочным часам, никакого мониторинга не проводит, а ответ _однозначно_ знает.
13 фев 12, 14:21    [12081627]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
Про часы странный вопрос - я меряю таймером естественно, точность до сотых сек, но на таких временных отрезках погрешность около 0,1 сек.
Про планы - я не знаю как эт опосмотреть в MSSQL Express. Не подскажете?
Я не специалист в БД, потому обращаюсь на форум к вам - специалистам.
Спасибо.
13 фев 12, 14:26    [12081674]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
https://www.sql.ru/faq/faq_topic.aspx?fid=393
13 фев 12, 14:27    [12081681]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
Glory
Member

Откуда:
Сообщений: 104751
victorovich
Про часы странный вопрос - я меряю таймером естественно, точность до сотых сек

А приводите почему то секунды ?
И что такое этот ваш таймер ?
victorovich
но на таких временных отрезках погрешность около 0,1 сек.

Какие еще погрешности ?

victorovich
Про планы - я не знаю как эт опосмотреть в MSSQL Express. Не подскажете?

Открыть в хелпе статью Displaying Execution Plans by Using the Showplan SET Options
13 фев 12, 14:30    [12081702]     Ответить | Цитировать Сообщить модератору
 Re: быстродействие и индексы - странный момент  [new]
victorovich
Member

Откуда:
Сообщений: 71
Реальный запрос такой (я чуть упростил в форуме, чтобы была суть понятна):

SELECT * FROM t1,t2 WHERE t2.user_locator=t1.id AND t1.user_name='user000' [AND datalength(t2.url)>0]

Так вот при включении в запрос datalength его генерация на сервере возрастает в ~1.5 раза. Меряю таймером, т.е. сколько выполняется сам select. Блок передаваемых данных совсем небольшой, передается за доли секунды, так что тут все в норме.

План показал след.:

|--Hash Match(Inner Join, HASH:([mydb].[dbo].[t1].[id])=([mydb].[dbo].[t2].[user_locator]),
RESIDUAL:([mydb].[dbo].[t2].[user_locator]=[mydb].[dbo].[t1].[id]))
|--Table Scan(OBJECT:([mydb].[dbo].[t1]), WHERE:([mydb].[dbo].[t1].[user_name]='user000'))

|--Filter(WHERE:([Expr1008]>(0)))
|--Compute Scalar(DEFINE:([Expr1008]=datalength([mydb].[dbo].[t2].[url])))


|--Table Scan(OBJECT:([mydb].[dbo].[t2]))

Жирным я выделил строчки, которые добавляются в запросе с datalength()
13 фев 12, 15:48    [12082420]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить