Воспламенение или нагревающийся кэш в SQL Server

Предоставление «ответа», чтобы попытаться проработать это, поскольку это то, что меня особенно интересует.

Я наткнулся на эта статья 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
{ {1}} 3) теперь запустите оператор SELECT TOP 1 '1' FROM MyTable
4) повторно запустите вышеуказанный запрос и посмотрите, что теперь появляется в результатах - вы вероятно, вы увидите запись (и) для MyTable, показывающую кэшированные страницы - запишите это число

. Это должно дать вам представление об уровне кэширования данных, который происходит для этого начального SELECT. Если вы повторите этот процесс еще раз, но вместо оператора SELECT TOP выполните свой sproc, а затем посмотрите, сколько заканчивается в кеше при его запуске - возможно, сравнение этих результатов покажет относительный объем кэширования, выполняемого SELECT TOP 1 по сравнению с вызовом sproc - и это относительное количество может указывать на улучшение производительности.

Это очень похоже на «размышления вслух». Я бы не подумал, что ТОП 1 действительно значительно загрузил бы кеш для вызова sproc, но именно поэтому меня интересует этот вопрос!

Сначала я подумал, что это больше связано с другими факторами (например, с нагрузкой на сервер / диск). Вы можете поочередно переключаться между двумя сценариями для 3 или 4 итераций, один за другим, чтобы дважды проверить, действительно ли подход SELECT TOP постоянно лучше (помогите минимизировать риск того, что это будет разовая ошибка)

Надежда это помогает / запускает мяч.

Обновление:
Теперь вы знаете, что не SELECT TOP заполняет кеш, хороший способ заполнить кеш, как сказал AdrianBanks.По крайней мере, теперь вы можете объяснить, что было неожиданным / сбивающим с толку разницей в производительности! Сохраните приведенный выше сценарий в своей библиотеке, он полезен для проверки состояния кеша.