У меня работает служба обменивающаяся принимающая заказы с сайта, записывающая их в базу MSSQL 2012 и высылающая их изменения в базе на сайт. Для высылки получения списка изменений (чтобы потом выслать их на сайт) использовалась одна хранимая процедура, которая пробегала каждый раз по всему списку заказов (огромному за несколько лет) искала изменения сверяя с датой последней синхронизации каждого заказа. И вызывалась она после записи каждого нового заказа (вообще в томже потоке). Я решил сделать чтобы после записи нового заказа она пробегала только по нему, и только через определенный тоже не очень большой интервал пробегала по всем. Там было также сделано чтобы если процедура выполняется дольше 100сек она обрывалась. Поставил в её запрос условие "and (@UID1='' or z.[UID]=@UID1)". И после этого начались чудеса. Сначала все было хорошо, заказы полетели намного быстрее потом спустя день в тех моментах где процедура выполнялась на всех заказах ( с параметром @UID1='') начались жуткие тормоза, она тормозила более чем в 5 раз дольше чем прежде, не укладывалась в лимит и обрывалась и так каждый раз. То есть практически сдохла. Я долго мучился с ней. Один раз запустишь сделает за пол секунды, а через минуту запустишь намертво зависнит. И в следующий раз продолжает виснуть, причем если её параметр переименовать (например из @UID2 в @UID2, то довольно долгое время начинает нормально работать). Какой-то дикий глюк MSSQL с построением плана запроса. И решил эту задачу (по крайней мере уже 2 недели работает) только написав в этой хранимой процедуре 2 отдельных запроса различающихся только строкой "z.[UID]=@UID1", то есть сделав так if @UID1='' запросПолный else запрос1заказ. Эстетически безобразно конечно, но по иному никак. Можете ли вы что-нибудь пояснить по поводу такого явления.

Весело с ней было. Параметр этот изначально назывался @UID. Я его переименовал, все сразу заработало. Я сразу придумал " UID - зарезервированное слово MSSQL и именно это причина всего...". Потом переименовал такие параметры ещё 4х других хранимых процедур, перелопатил массу кода где они упоминались и даже в репозитории-тортузе написал сообщение "Никогда, никогда не используйте параметры @UID"

felix_ff,

Это то я потом понял, когда спустя выходные снова перестало работать. См первое сообщение. А тогда такая логически стройная картина нарисовалась, прямо думал открытие совершил.

Я ешё год или два назад заметил что случались зависания если параметры хранимой процедуры по-умолчанию = NULL и участвуют в запросе. Это миф из той же серии или действительно что-то такое есть?

Дедушка,

значит чтобы процедура работала стабильно независимо от каких-нибудь директив лучше чтобы параметры не участвовали в запросах в хранимой процедуре, а передавались переменным. Спасибо, не знал о таком, учту

У меня поле [UID] - первичный ключ таблицы. Название отвратительное, зарезервированное MSSQL, но пока не меняем. И это varchar(50). Понимаю что это тоже плохо и неудобно. От сайта на котором заказы делаются это повелось, пока тоже менять не будем. Параметр @UID1 это либо ключ причем только что добавленное значение либо @UID1=''. Я недавно перенес вызов с @UID1='' в отдельный процесс, потом как-нибудь в отдельном потоке одного процесса сделаю.