Времена запроса в.Net SqlCommand. ExecuteNonQuery, работы в Studio управления SQL Server
Цитата> Мой вопрос: каково правило о количестве vptr в наследовании?
Правил нет, каждому поставщику компилятора разрешается реализовывать семантику наследования так, как он считает нужным.
класс B: общедоступный A {}, размер = 12. Это довольно нормально, одна таблица для B, в которой есть оба виртуальных метода, указатель таблицы + 2 * int = 12
класс C: общедоступный A, общедоступный B {}, размер = 20. C может произвольно расширить виртуальную таблицу A или B. 2 * указатель виртуальной таблицы + 3 * int = 20
Виртуальное наследование: вот где вы действительно достигли краев недокументированного поведения. Например, в MSVC параметры компиляции #pragma vtordisp и / vd становятся актуальными. Есть некоторая справочная информация в этой статье . Я изучил это несколько раз и решил, что аббревиатура опции компиляции является репрезентативной для того, что может случиться с моим кодом, если я когда-либо его использую.
7 ответов
Проверено, и этот сервер, являющийся сервером разработки, не работал под управлением SQL Server 2005 SP3. Пытался установить (с необходимой перезагрузкой), но не установился. Как ни странно, теперь и код, и SSMS возвращаются за субсекунду.
Woot, это HEISENBUG.
Это не ваши индексы.
Это анализ параметров, как это обычно происходит с параметризованными хранимыми процедурами. Это не так широко известно даже среди тех, кто знает об отслеживании параметров, но это также может произойти, когда вы используете параметры через sp_executesql.
Вы заметите, что версия, которую вы тестируете в SSMS, и версия профилировщика показы не идентичны, потому что версия профилировщика показывает, что ваше приложение .Net выполняет его через процедуру sp_executesql. Если вы извлечете и выполните полный текст sql, который на самом деле выполняется для вашего приложения, то я считаю, что вы увидите ту же проблему производительности с тем же планом запроса.
К вашему сведению: различия в планах запросов являются ключевым показателем анализ параметров.
ИСПРАВЛЕНИЕ: Самый простой способ исправить это, предполагая, что он выполняется на SQL Server 2005 или 2008, - это добавить предложение «OPTION (RECOMPILE)» в последней строке вашего оператора SELECT. Предупреждаем, вам, возможно, придется выполнить его дважды, прежде чем он заработает, и он не всегда работает на SQL Server 2005. Если это произойдет, вы можете предпринять другие шаги, но они немного сложнее.
Одна вещь, которую вы можете попробовать, - это проверить, включена ли «Принудительная параметризация» для вашей базы данных (она должна быть в свойствах базы данных SSMS на странице «Параметры»). Чтобы настроить отключение принудительной параметризации, выполните следующую команду:
ALTER DATABASE [yourDB] SET PARAMETERIZATION SIMPLE
Я уже сталкивался с этой проблемой раньше. Похоже, ваши индексы вышли из строя. Чтобы получить такое же поведение в SSMS, добавьте это перед скриптом
SET ARITHABORT OFF
. Тайм-аут тоже? Если да, то это ваша индексация и статистика
Раньше я работал в нерабочее время с индексами, и я получил тот же результат, что и вы. sp_recompile может перекомпилировать sproc ... или, если это не сработает, sp_recompile может быть запущен в таблице, и все sproc, которые действуют в этой таблице, будут перекомпилированы - у меня работает каждый раз.
Скорее всего, это связано с индексом. Была аналогичная проблема с приложением .Net и SSMS (в частности, в процессе с использованием временной таблицы с <100 строк). Мы добавили кластерный индекс в таблицу, и после этого он улетел из .Net.
Я видел такое поведение раньше, и это может быть большой проблемой для программ отображения o / r, которые используют sp_executesql. Если вы изучите планы выполнения, вы, вероятно, обнаружите, что запрос sp_executesql не очень хорошо использует индексы. Я потратил довольно много времени, пытаясь найти решение или объяснение этого поведения, но так и не добился успеха.
Скорее всего, ваши .Net-программы передают переменные как NVARCHAR , а не как VARCHAR . Ваши индексы находятся в столбцах VARCHAR, как я полагаю (судя по вашему скрипту), и условие вроде ascii_column = @unicodeVariable на самом деле не поддерживает SARG. План должен генерировать сканирование в этом случае, когда в SSMS будет генерироваться поиск, потому что переменная имеет правильный тип.
Убедитесь, что вы передаете всю свою строку как параметры VARCHAR, или измените свой запрос, чтобы явно привести переменные, вот так:
SELECT dv.ID
FROM dbo.DictionaryValue AS dv
WHERE dv.Word LIKE '%' + CAST(@FieldCheckValue5 AS VARCHAR(128)) + '%'