Каковы практические последствия предупреждения sys.dm_exec_query_stats в документации?

Документация для sys.dm_exec_query_statsследующих государств:

Первоначальный запрос sys.dm_exec_query_stats может привести к неточным результатам, если на сервере в настоящий момент выполняется рабочая нагрузка. Более точные результаты могут быть определены путем повторного выполнения запроса.

Иногда я запрашиваю этот DMV во время активной рабочей нагрузки и предпочитаю точные результаты. Я не знаю, как применить вышеупомянутое предупреждение на практике. Должен ли я всегда запрашивать DMV дважды и использовать второй набор результатов, потому что это будет более точным? Это кажется немного надуманным. Нужно ли мне знать, каким образом DMV может быть неточным, чтобы я мог учесть это в своем анализе? Если да, то какие могут быть неточности: пропущенные строки, устаревшие значения, несогласованные строки или что-то еще?

Каковы лучшие практики при использовании sys.dm_exec_query_statsво время активной рабочей нагрузки?

Я обновил документацию, чтобы быть более простым в формулировке. Цель состояла в том, чтобы сообщить пользователю, что выполнение запроса к DMV будет производить вывод только для элементов, которые были выполнены, а не для элементов в полете. Таким образом, запустите рабочую нагрузку полностью, чтобы убедиться, что все захвачено.

Новая формулировка будет следующей и применима к различным DMV, в которые была включена предыдущая формулировка.

Результаты sys.dm_exec_query_stats могут различаться при каждом выполнении, поскольку данные отражают только завершенные запросы, а не те, которые еще находятся в процессе выполнения.

Я не знаю, как применить вышеупомянутое предупреждение на практике.

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

Я быстро взглянул на реализацию в SQL Server 2017 CU 15 и, похоже, нет особой причины ожидать несоответствия (или «неточности»), за исключением того, что итоговые значения обновляются только в конце выполнения каждого оператора .