Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. В последнее время ряд запросов в Management Studio перестал выполняться. Речь идет о запросах с перечислением большого количества значений в in ( ... ) Пример: select * from clientdata where dtdelete is null and regno in ( ... ) order by regno asc - выдает ошибку "Сообщение 8632, уровень 17, состояние 2, строка 1 - Внутренняя ошибка: был достигнут предел служб выражений. Проверьте потенциально сложные выражения в запросе и постарайтесь их упростить." select c.regno, convert(varchar, s.dtopen, 104) from ClientData c join ClientScheta s on c.FID=s.posc where c.dtdelete is null and c.regno in ( ... ) order by regno asc - выдает ошибку "Сообщение 8623, уровень 16, состояние 1, строка 1 - Обработчик запросов исчерпал внутренние ресурсы, и ему не удалось предоставить план запроса. Это редкое событие, которое может происходить только при очень сложных запросах или запросах, которые обращаются к очень большому числу таблиц или секций. Упростите запрос. Если предполагается, что это сообщение получено по ошибке, свяжитесь со службой поддержки для получения дополнительных сведений." Раньше подобные запросы выполнялись нормально для 100 000+ значений в in, а сейчас не хотят даже с ~60 000... Предела оперативной памяти в момент выполнения запроса сервер не достигает. С чем может быть связано такое ухудшение производительности и как решить данную проблему? Версия SQL - Microsoft SQL Server 2012 - 11.0.2100.60 (X64) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 11:54 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitС чем может быть связано такое ухудшение производительности С тем, что в хелпе заранее предупредили Including an extremely large number of values (many thousands) in an IN clause can consume resources and return errors 8623 or 8632. To work around this problem, store the items in the IN list in a table. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 11:57 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
IN-список откуда и как формируется? что мешает засунуть его в таблицу (табличную переменную, врменную таблицу) и сделать JOIN вместо IN ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 11:57 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbit100 000+ значений в inСилён... а во временную таблицу их скинуть не хочешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 11:57 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Добрый Э - ЭхIN-список откуда и как формируется? что мешает засунуть его в таблицу (табличную переменную, врменную таблицу) и сделать JOIN вместо IN ?Зачем JOIN? IN, но только IN(SELECT....) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 11:59 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitС чем может быть связано такое ухудшение производительности и как решить данную проблему? Версия SQL - Microsoft SQL Server 2012 - 11.0.2100.60 (X64)Связано с изменением оптимизатора, компилятора. Решить можно переписыванием запроса. Например, вставлять эти значения во временную таблицу. Вряд ли эти "100 000+ значений в in" набирались руками, так что наверное несложно переписать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:06 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
iap, не любли IN-subquery ещё с тех пор, когда оптимизатор сам не умел их "разворачивать" в джойны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:11 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Заставляет задуматься о соответствии программиста его занимаемой должности... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:11 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эхiap, не любли IN-subquery ещё с тех пор, когда оптимизатор сам не умел их "разворачивать" в джойны.В списке может оказаться не по одному экземпляру некоторых значений... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:13 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
iap, distinct никто не отменял. как на список перед вставкой в таблицу, так и при джойне на селект из таблицы-списка или на результат всего джойна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:27 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Добрый Э - Эхiap, distinct никто не отменял. как на список перед вставкой в таблицу, так и при джойне на селект из таблицы-списка или на результат всего джойна.А чем это лучше? DISTINCT - гарантия торможения запроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:39 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Вообще, IN() я тоже не люблю. Всегда пишу EXISTS() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:40 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Благодарю за информацию. Со временными таблицами логично, так в итоге и сделал. Хотел просто понять, почему то, что раньше выполнялось без проблем, выполняться вдруг перестало. Владислав КолосовЗаставляет задуматься о соответствии программиста его занимаемой должности... Никогда такой должности не занимал и не планирую.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 12:58 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitХотел просто понять, почему то, что раньше выполнялось без проблем, выполняться вдруг перестало. Потому что "Including an extremely large number of values " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:00 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Glory, Раньше точно такой же запрос с еще большим "number of values" выполнялся без проблем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:04 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitGlory, Раньше точно такой же запрос с еще большим "number of values" выполнялся без проблем. Ну так вернитесь во времени назад ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:05 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitРаньше точно такой же запрос с еще большим "number of values" выполнялся без проблем. У меня тут давеча соседка померла. До того 75 лет прожила, и ни разу с ней раньше такой фигни не случалось... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:10 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitGlory, Раньше точно такой же запрос с еще большим "number of values" выполнялся без проблем. Я еще в 2006-2007 году делал оптимизации, где подобные IN валились по ошибке и приходилось, если число ID-шнишников выше разумной величины, класть их во временную таблицу и оттуда IN (SELECT ID FROM #T). И валилось это дело уже где-то после 500-1000 значений. Там скрипт длинный собирался динамически. Если вам надо их непременно вставить в скрипт, то вставляйте порциями через VALUES по 50-100 шт, потом на эту таблицу In (а лучше JOIN). Таким способом можно больше передать в запросе. И об индексе надо подумать. Но, ИХМО, что-то у вас не так архитектурно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:10 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
AkinaPROrabbitРаньше точно такой же запрос с еще большим "number of values" выполнялся без проблем. У меня тут давеча соседка померла. До того 75 лет прожила, и ни разу с ней раньше такой фигни не случалось... Если померла, значит были на то причины (болезнь, критический износ комплектующих). У нашего сервера подобных проблем не наблюдается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:32 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitУ нашего сервера подобных проблем не наблюдается. Вам еще раз процитировать хелп ? Including an extremely large number of values (many thousands) in an IN clause can consume resources and return errors 8623 or 8632. To work around this problem, store the items in the IN list in a table. У вас есть many thousands, как вы думате ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:34 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Glory, Я читал и хелп и множество других вещей на этот счет. Суть проблемы заключается в том, что при визуально идентичных ситуациях имеется разный результат. При неизменной структуре БД и 100% идентичных запросах месяц назад мы имели успешную отработку, а сегодня ошибку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:40 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitЯ читал и хелп и множество других вещей на этот счет. Суть проблемы заключается в том, что при визуально идентичных ситуациях имеется разный результат. При неизменной структуре БД и 100% идентичных запросах месяц назад мы имели успешную отработку, а сегодня ошибку. Ваши рассуждения из серии - я всегда здесь переходил дорогу, а сегодня меня тут сбила машина. Сервер использовал свое право "can consume resources and return errors 8623 or 8632" Какая еще суть вам нужна ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:42 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
Glory, Если возникла проблема, стоит разобраться почему именно. Если сервер вдруг "воспользовался правом", значит у него на это были причины. Можно сказать, что на это "воля господня" и не разбираться в проблеме, а можно попытаться найти моменты, которые изменились, будь то процент выделения процессорного времени, версия обновления сервера, изменение конфигурации и т.д... Вот я и хочу понять, в какую сторону копать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 13:57 |
|
||
|
Ухудшение производительности запросов с in ( .. )
|
|||
|---|---|---|---|
|
#18+
PROrabbitЕсли возникла проблема, стоит разобраться почему именно. Разумеется. Причина - это large number of values. PROrabbitЕсли сервер вдруг "воспользовался правом", значит у него на это были причины. Вы можете начать поиск этих причин. Только зачем, если запрос все равно придется перписать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.07.2015, 14:01 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=38996696&tid=1687320]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
88ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
85ms |
get tp. blocked users: |
2ms |
| others: | 261ms |
| total: | 489ms |

| 0 / 0 |
