Это немного долго; но я работал с запросами, выясняя, откуда исходит проблема с производительностью. Благодарю, что вы нашли время прочитать его.
У меня есть приложение, работающее на выделенном сервере, который в свою очередь работает под управлением SQL Server 2012 @ Azure (Западная Европа, если это имеет значение). Мое приложение не будет работать в общей службе из-за пробелов в функциональности в Azuresql. В прошлом запущенное приложение работало на всех серверах 2012 года, и я замечаю странную аномалию производительности между Azure и другими серверами SQL, отличными от Azure.
Проблема связана с временными таблицами - снова таблицы переменных v # таблицы.
Мы обнаружили в Azure, что в таблицах вариантов продолжительность запросов значительно больше; очень простой пример; выполнить по 50 раз и усреднить.
Create table #table (contactid uniqueidentifier, AnotherID uniqueidentifier)
insert into #table
select top 100 contactid, AnotherID
from dbo.pdContacts
v
declare @table table (contactid uniqueidentifier, AnotherID uniqueidentifier)
insert into @table
select top 100 contactid, AnotherID
from dbo.pdContacts
Profiler сообщает, что средняя статистика составляет;
Variable Table : #Table
CPU 47 : 16
Reads 379 : 204
Writes 11 : 0
Duration 83 : 42
Тот же запрос, базы данных на выделенном сервере и без нагрузки.
Variable Table : #Table
CPU 16 : 16
Reads 873 : 898
Writes 11 : 0
Duration 5 : 15
В моем очень простом тесте продолжительность выполнения теста Azure Variant почти в два раза больше, чем у #table; на автономном оборудовании вариант значительно быстрее (что для небольших таблиц согласуется с тем, как мы его видели). Что ограничивает производительность таблиц вариантов, что более заметно в Azure, чем на автономных машинах; Я могу справиться с проблемами производительности в краткосрочной перспективе, но предпочитаю оптимизировать приложение для Azure за счет всех остальных.
Спасибо