Время процессора или прошедшее время-что на самом деле означает производительность SQL-запроса?

у меня есть таблица SQL server 2012 с 2697 записями, и таблица не индексируется. Данные будут увеличены в будущем до 100k записей. Я не присоединяюсь к какой-либо другой таблице с этой, Чтобы получить записи. Изначально я создал пользовательскую функцию для извлечения записей из таблицы.

позже я узнал, что представление будет быстрее, чем пользовательская функция, и поэтому я создал представление для этой таблицы.

чтобы узнать производительность запроса, I Включены следующие коды, чтобы получить время процессора и истекшее время моего UDF, VIEW и direct SQL statement.

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

когда я вытащил данные из таблицы с помощью запроса SELECT, я получил ниже процессорного времени и времени

SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

---- результат

Scan count 1, logical reads 1338, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
 SQL Server Execution Times:
   CPU time = 31 ms,  elapsed time = 4381 ms.

когда я использовал представление, я получил время процессора и истекшее время как

CREATE VIEW vw_testdata
AS
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata]

-- Result

Scan count 1, logical reads 1324, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
       CPU time = 15 ms,  elapsed time = 5853 ms.

и мой UDF вернулся как

CREATE FUNCTION [dbo].[fn_DocApproval] (@collegename nvarchar(30) = NULL)
RETURNS TABLE 
AS
RETURN  
(
SELECT [CollegeName]
      ,[CandidateID]
      ,[age]
      ,[race]
      ,[sex]
      ,[ethnic]
      ,[arm]
      ,[Weeknum]
      ,[siteid]
      ,[country]
      ,[Region]
      ,[SubRegion]
      ,[SNAME]
      ,[UID]
  FROM [testdata] WHERE CollegeName = ISNULL(@collegename, collagename)
)

-- результат

Scan count 1, logical reads 1338, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
 SQL Server Execution Times:
   CPU time = 203 ms,  elapsed time = 785 ms.

UDF имеет очень меньшее прошедшее время, чем прямой sql и представление, однако время процессора больше.

однако время процессора меньше в представлении по сравнению с direct SQL и UDF.

Я хочу знать, какой из них нам нужно искать, чтобы определить производительность запроса.

также почему меняется время процессора и прошедшее время, когда я запускал один и тот же запрос каждый раз?

моя схема и образец данныеСкрипка

в настоящее время у меня 2697 строк, и я не могу загрузить их все в fiddle.

2 ответов


в статье настройка производительности SQL-запросов

время синтаксического анализа и компиляции SQL Server: когда мы отправляем запрос на SQL server для выполнения, он должен проанализировать и скомпилировать любую синтаксическую ошибку, а оптимизатор должен создать оптимальный план выполнения. Время синтаксического анализа и компиляции SQL Server - это время, затраченное на выполнение этих предварительных шагов.Если вы посмотрите на результат второго выполнения, время процессора и прошедшее время равны 0 в SQL Server parse и Раздел времени компиляции. Это показывает, что SQL server не тратил время на синтаксический анализ и компиляцию запроса, поскольку план выполнения был легко доступен в кэше. CPU time относится к фактическому времени, затрачиваемому на CPU, а затраченное время относится к общему времени, затраченному на завершение синтаксического анализа и компиляции. Разница между временем процессора и истекшим временем может ждать в очереди, чтобы получить цикл процессора, или он ждал завершения ввода-вывода. Это не имеет большого значения в настройка производительности как значение будет варьироваться от выполнения к выполнению. Если вы получаете согласованное значение в этом разделе, вероятно, вы будете запускать процедуру с опцией перекомпиляции.

время выполнения SQL Server: это относится к времени, затрачиваемому SQL server на выполнение скомпилированного плана. CPU time относится к фактическому времени, затрачиваемому на CPU, где по прошествии времени общее время для завершения выполнения, которое включает в себя время ожидания сигнала, время ожидания для завершения операция ввода-вывода и время, необходимое для передачи вывода клиенту.Время процессора может использоваться для базовой настройки производительности. Это значение не будет сильно отличаться от выполнения к выполнению, если вы не измените запрос или данные. Нагрузка на сервер не сильно повлияет на это значение. Обратите внимание, что время отображается в миллисекундах. Значение времени процессора может варьироваться от выполнения к выполнению для того же запроса с теми же данными, но это будет только в 100, что является только частью секунды. Этот прошедшее время будет зависеть от многих факторов, таких как нагрузка на сервер, нагрузка ввода-вывода ,пропускная способность сети между сервером и клиентом. Поэтому всегда используйте время процессора в качестве базовой линии при настройке производительности.

чем меньше логических считываний у вас в плане, тем эффективнее запрос.


Если вы используете современный сервер, всегда смотрите на "истекшее время", а не на"время процессора". В эпоху быстрых многоядерных процессоров, многопроцессорных плат и так далее - важны все остальные факторы, обусловливающие быструю реакцию, а не процессор. Бывает, что при сложных запросах индикация времени процессора в 5 раз превышает общее время (проверьте "план выполнения" - тогда будет много параллелизмов).