Предоставление «ответа», чтобы попытаться решить эту проблему, поскольку это то, что меня особенно интересует.
Я наткнулся на эту статью MSDN о том, как посмотреть, что находится в кэше SQL Server.
Там есть запрос, который покажет вам, сколько страниц данных кэшируется объектом - я настроил его просто для включения имени индекса, как показано ниже:
SELECT count(*) AS cached_pages_count, obj.name, index_id, i.name AS IndexName
FROM sys.dm_os_buffer_descriptors AS bd
INNER JOIN
(
SELECT object_id, object_name(object_id) AS name
,index_id ,allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.hobt_id
AND (au.type = 1 OR au.type = 3)
UNION ALL
SELECT object_id, object_name(object_id) AS name
,index_id, allocation_unit_id
FROM sys.allocation_units AS au
INNER JOIN sys.partitions AS p
ON au.container_id = p.partition_id
AND au.type = 2
) AS obj
ON bd.allocation_unit_id = obj.allocation_unit_id
LEFT JOIN sysindexes i ON obj.object_id = i.id AND obj.index_id = i.indid
WHERE database_id = db_id()
GROUP BY obj.name, index_id, i.name
ORDER BY cached_pages_count DESC;
Если вы попытаетесь выполнить следующие шаги, вы сможете увидеть, что происходит с кэшированием. Сделайте это в своей базе данных (в отличие, например, от master):
1) контрольная точка + очистка кеша
2) запустите приведенный выше запрос, и вы, вероятно, получите 1 возвращенную запись (для sysobjvalues), но ничего для Table1
3) теперь запустите оператор SELECT TOP 1 '1' FROM MyTable
4) повторно запустите приведенный выше запрос и посмотрите, что теперь появляется в результатах - вы, вероятно, увидите записи для MyTable, показывающие кэшированные страницы - запишите это число
Это должно дать вам представление об уровне кэширования данных, которое происходит для этого начального SELECT. Если вы повторите процесс до конца, но вместо оператора SELECT TOP выполните sproc, а затем посмотрите, сколько окажется в кэше при его запуске - возможно, сравнение этих результатов покажет относительный объем кэширования, который выполняется ВЫБЕРИТЕ ТОП 1 по сравнению с вызовом sproc - и эта относительная величина может указывать на улучшение производительности.
Это очень много "продуманных вслух" вещей. Я бы не подумал, что ТОП-1 действительно значительно заполнил бы кэш для вызова sproc, но именно поэтому меня интересует этот вопрос!
Сначала я бы подумал, что это связано с другими факторами (например, нагрузка на сервер / диск). Вы можете переключаться между двумя сценариями для 3 или 4 итераций, одна за другой, чтобы дважды проверить, действительно ли подход SELECT TOP действительно лучше (помочь минимизировать риск того, что он будет одноразовым)
Надеюсь, это поможет / заставит шарик катиться.
Обновление:
Теперь вы знаете, что это не SELECT TOP, который заполняет кеш, хороший способ заполнить кеш, как сказал AdrianBanks. По крайней мере, теперь вы можете объяснить, что было неожиданным / сбивающим с толку разницу в производительности! Сохраните приведенный выше скрипт в своей библиотеке, это полезно для проверки состояния кэша.