Народ, есть ли способы помочь серверу выполнить запрос:
SELECT * FROM Table WHERE field1 <= const AND const <= field2
field1, field2 — поля таблицы типа INT
field1 <= field2 или это всегда перебор всех записей в таблице?
> Народ, есть ли способы помочь серверу выполнить запрос: > SELECT * FROM Table WHERE field1 <= const AND const <= field2 > field1, field2 — поля таблицы типа INT > field1 <= field2 или это всегда перебор всех записей в таблице?
Сервер какой?
Индексы какие есть?
Каков текущий план выполнения запроса?
Смотря насколько помочь. На бытовом уровне индекс по (field1, field2) либо по любому из этих полей может пригодиться, если условие выбора селективно. А на более серьёзном — смотреть, как в используемой СУБД поддерживаются r-индексы.
Здравствуйте, Didi, Вы писали:
D>Народ, есть ли способы помочь серверу выполнить запрос: D>SELECT * FROM Table WHERE field1 <= const AND const <= field2 D>field1, field2 — поля таблицы типа INT D>field1 <= field2 или это всегда перебор всех записей в таблице?
SELECT * FROM Table WITH(NOLOCK)
WHERE field1 <= const AND const <= field2
Здравствуйте, Didi, Вы писали:
D>Народ, есть ли способы помочь серверу выполнить запрос: D>SELECT * FROM Table WHERE field1 <= const AND const <= field2 D>field1, field2 — поля таблицы типа INT D>field1 <= field2 или это всегда перебор всех записей в таблице?
Когда пытался понять что такое CROSS APPLY наткнулся на такую статью. Возможно поможет, хотя тут инвертированное условие.
Мда, вам не повезло... Вот к примеру народ тоже страдает.
В общем случае да, будет перелопачена часть индекса или вообще вся таблица. Проблема вот в чем. Допустим в вашей таблице миллион записей и field1 содержит все числа от 1 до 1 млн. А теперь допустим вы ищете const = 500000. Произойдет то, что в лучшем случае серверу придеться перелопатить 500000 записей в индексе, если он селективный, в худшем сделать полный table scan. И это будет самое лучшее, что можно придумать.
Но, безвыходных ситуаций нет! Подумайте какие еще условия у вас есть для field1/field2. К примеру, если вы знаете, что max(field2-field1) меньше относительно небольшой константы (назовем ее max_len), то можете добавить условие
SELECT * FROM Table WHERE field1 <= const AND field1 >= const — max_len AND const <= field2
может значительно ускорить выборку.
У меня была задача поиска по отрезкам IP адресов в многомиллионной таблице. Этот поход сработал на ура. В вашем может быть еще что-нибудь.
D>Народ, есть ли способы помочь серверу выполнить запрос: D>SELECT * FROM Table WHERE field1 <= const AND const <= field2 D>field1, field2 — поля таблицы типа INT D>field1 <= field2 или это всегда перебор всех записей в таблице?
Здравствуйте, Vaako, Вы писали:
V>SELECT * FROM Table WITH(NOLOCK) V>WHERE field1 <= const AND const <= field2
V>ускорит
А то... И вылезет геморроем в тольких местах, что проще будет все убить и написать заново. Как раз сейчас такую БД ковыряю изнутри. Продакшн, и успешный... Но вот за вот эти NOLOCK просто поотрывал бы все.
Здравствуйте, LuciferArh, Вы писали:
LA>Здравствуйте, Vaako, Вы писали:
V>>SELECT * FROM Table WITH(NOLOCK) V>>WHERE field1 <= const AND const <= field2
V>>ускорит
LA>А то... И вылезет геморроем в тольких местах, что проще будет все убить и написать заново. Как раз сейчас такую БД ковыряю изнутри. Продакшн, и успешный... Но вот за вот эти NOLOCK просто поотрывал бы все.
Так думать же надо куда вставлять а куда нет, а без них тормоза буду неслабые. Кто не использует NOLOCK вообще тот лох.
Здравствуйте, LuciferArh, Вы писали:
LA>А то... И вылезет геморроем в тольких местах, что проще будет все убить и написать заново. Как раз сейчас такую БД ковыряю изнутри. Продакшн, и успешный... Но вот за вот эти NOLOCK просто поотрывал бы все.
А можно кровавых подробностей? Просто тоже наблюдаю кучу NOLOCK по поводу и без (я знаю что это read uncommitted), но какие именно проблемы могут при этом вылезти?
Здравствуйте, Somescout, Вы писали:
S>А можно кровавых подробностей? Просто тоже наблюдаю кучу NOLOCK по поводу и без (я знаю что это read uncommitted), но какие именно проблемы могут при этом вылезти?
Если без кода (нет его под рукой), то запросто. Имеем процедуру расчета оперативного баланса. По неким причинам, сие действо запланировано на исполнение раз в 15 минут, хотя по логике надо бы раз в пять минут. Ну да ладно. Встал вопрос о том, что запуск сей процедуры надо бы делать раз в 20, а то и 30 минут, ибо оно не успевает отрабатывать. (Немного о железе: двухпроцессорный ксеон (по факту — 16 ядер), 32 гига оперативы, 4 SSD в 10 рейде). Примерное количество клиентов онлайн, по которым надо отрабатывать, — 350-360 (зависит от активности). Обрабатываются четыре таблицы, примерно пять тысяч строк(!!!). Время отрабатывания задания — 12(!!!) минут. В теле процедуры на каждом шагу WITH (NOLOCK) и create table #bla-bla. С кучей инсертов в темповые таблицы, курсорам по ним и апдейтами оных эе с последующим итоговым апдейтом целевой нужной нам таблицы.
В общем, выкинул я всю эту бодягу. В итоге процедура отрабатывает за 15 секунд. Клиенты счастливы и довольны. И такого кода я за последний месяц "оптимизировал" (то есть, попросту снес в помойку) уже несчитано. Разработчик предложил контракт.
Здравствуйте, Somescout, Вы писали:
S> (я знаю что это read uncommitted), но какие именно проблемы могут при этом вылезти?
Проблемы с согласованностью данных, они вылезают, если использующий NOLOCK не понимает, что это read uncommitted; и/или не может оценить его пригодность /в конкретном случае.
Hardware eventually fails. Software eventually works. ::: avalon/1.0.442
Здравствуйте, LuciferArh, Вы писали:
LA>Здравствуйте, Somescout, Вы писали:
S>>А можно кровавых подробностей? Просто тоже наблюдаю кучу NOLOCK по поводу и без (я знаю что это read uncommitted), но какие именно проблемы могут при этом вылезти?
LA>Если без кода (нет его под рукой), то запросто. Имеем процедуру расчета оперативного баланса. По неким причинам, сие действо запланировано на исполнение раз в 15 минут, хотя по логике надо бы раз в пять минут. Ну да ладно. Встал вопрос о том, что запуск сей процедуры надо бы делать раз в 20, а то и 30 минут, ибо оно не успевает отрабатывать. (Немного о железе: двухпроцессорный ксеон (по факту — 16 ядер), 32 гига оперативы, 4 SSD в 10 рейде). Примерное количество клиентов онлайн, по которым надо отрабатывать, — 350-360 (зависит от активности). Обрабатываются четыре таблицы, примерно пять тысяч строк(!!!). Время отрабатывания задания — 12(!!!) минут. В теле процедуры на каждом шагу WITH (NOLOCK) и create table #bla-bla. С кучей инсертов в темповые таблицы, курсорам по ним и апдейтами оных эе с последующим итоговым апдейтом целевой нужной нам таблицы.
LA>В общем, выкинул я всю эту бодягу. В итоге процедура отрабатывает за 15 секунд. Клиенты счастливы и довольны. И такого кода я за последний месяц "оптимизировал" (то есть, попросту снес в помойку) уже несчитано. Разработчик предложил контракт.
NOLOCK — это грязное чтение и не может затормозить еще больше тормознутую процедуру
Здравствуйте, Vaako, Вы писали:
V>NOLOCK — это грязное чтение и не может затормозить еще больше тормознутую процедуру
Я знаю. Зато оно может так искалечить данные, что потом без поллитрые и не понять, что реальность, а что дикий вымысел, порожденный NOLOCK. Обрабатываемые данные обязаны быть чистыми, консистентными и достоверными. И вот как раз NOLOCK с прочими ухищрениями тут не нужен от слова совсем.
Здравствуйте, LuciferArh, Вы писали:
S>>А можно кровавых подробностей? Просто тоже наблюдаю кучу NOLOCK по поводу и без (я знаю что это read uncommitted), но какие именно проблемы могут при этом вылезти? LA>Если без кода (нет его под рукой), то запросто. Имеем процедуру расчета оперативного баланса. Время отрабатывания задания — 12(!!!) минут. В теле процедуры на каждом шагу WITH (NOLOCK) и create table #bla-bla. С кучей инсертов в темповые таблицы, курсорам по ним и апдейтами оных эе с последующим итоговым апдейтом целевой нужной нам таблицы. LA>В общем, выкинул я всю эту бодягу. В итоге процедура отрабатывает за 15 секунд.
И конечно же главный виновник — НОЛОК.
Здравствуйте, rFLY, Вы писали:
FLY>И конечно же главный виновник — НОЛОК.
Не главный, но он запихивал в обработку фантомные записи, которых быть не должно. Что тоже не добавляло скорости работы.
FLY>PS: 15 секунд дофига, для обработки 5к записей.
Это не дофига, это нормально. Там еще вычислений много. Сегодня я еще раз прошелся по процедуре, подобавлял индексы и статистики — 2 секунды в итоге. Что после 12 минут, согласись, весьма и весьма... Эх, серверу бы еще памяти добавить бы, да сервиспаки поставить... А то предыдущему админу было все до фени, как поставил голый RTM, так и забил на все.
Здравствуйте, LuciferArh, Вы писали:
FLY>>И конечно же главный виновник — НОЛОК. LA>Не главный, но он запихивал в обработку фантомные записи, которых быть не должно. Что тоже не добавляло скорости работы.
Да брось, кол-во таких записей ничтожно для того чтобы их учитывать (я сейчас о времени говорю, а не о целостности данных). Ну сколько 360 человек, даже если одновременно ломанутся добавлять, смогут создать записей?
FLY>>PS: 15 секунд дофига, для обработки 5к записей. LA>Это не дофига, это нормально. Там еще вычислений много. Сегодня я еще раз прошелся по процедуре, подобавлял индексы и статистики — 2 секунды в итоге.
2 сек на 5к записей не 15 как было, согласись, пусть даже с учетом вычислений.
Здравствуйте, rFLY, Вы писали:
FLY>Да брось, кол-во таких записей ничтожно для того чтобы их учитывать (я сейчас о времени говорю, а не о целостности данных). Ну сколько 360 человек, даже если одновременно ломанутся добавлять, смогут создать записей?
Дело не в том, сколько они создадут записей. Дело в качестве этих записей, когда у клиентов появятся совершенно левые цифры, ломающие все.
Вот к примеру народ тоже страдает. 
