Вопрос о статистике времени, плане выполнения и «печати»

Question

Пытаясь определить, какая область большого запроса вызывает проблемы с производительностью, я сделал три шага. В том числе план выполнения, включение статистики времени и печать непосредственно перед и после разделов, которые, как я считаю, могут вызвать проблемы. Пример:

print '1'
SELECT ID FROM Test
print '2'

Когда я смотрю на свой план выполнения, он говорит, что определенный раздел занимает большой процент от «стоимости». Когда я сравниваю этот процент с истекшим временем между моими print '1' и print '2', кажется, что этот процент не может быть даже близок.

Безопасно ли полагаться на напечатанные значения и статистику времени по сравнению с расчетной стоимостью? Если это так, то имеет ли смысл для меня сосредоточиться на областях, которые имеют большой промежуток времени между печатными значениями, а не сметными затратами?

Answer 1

Если вы печатаете только «1» и печатаете «2», то измеряйте время между тем, когда вы видите сообщение на панели сообщений SSMS, тогда вы становитесь жертвой буферизации вывода между сервером и клиентом. print '1' может не сразу отправляться обратно клиенту, а SqlClient, ADO.Net и SSMS также выполняют некоторую собственную буферизацию. Таким образом, в целом вы можете увидеть «1» на панели сообщений о результатах SSMS, намного позже, чем это произошло на самом деле. Гораздо лучше вывести время из getdate (), а не просто «1». Таким образом вы удаляете буферизацию из уравнения и можете видеть в самом сообщении время, когда сервер выполнил «печать», а не время, когда его вывод отображался SSMS.

SET STATISTICS TIME ON всегда будет более точным, но иногда трудно понять, к какому именно утверждению оно относится.

То, что я обычно делаю, выглядит примерно так:

declare @nowString varchar(100);
declare @start datetime, @end datetime, @rc int, @elapsed int;

set @start = getdate();

select many, fields 
from bigtable 
join manytables on condition = complex 
where matches = many
order by wacky sort;

set @rc = @@rowcount;
set @end = getdate();
set @elapsed = datediff(ms, @start, @end);
set @nowString = cast(varchar(100), getdate(), 14);
raiserror(N'%s: At select No 1. Selected %i rows in %i ms', 10, 1, %nowString, @rc, @elapsed);

set @start = getdate();
...next select here...

Answer 2

Это небезопасная ставка, потому что операторы PRINT буферизируются для вывода - они не являются немедленными. План выполнения - это хорошее место для поиска проблем с производительностью, так как он определяет, где находятся самые дорогие компоненты, и помогает определить такие вещи, как отсутствующие индексы (например, если вы просматриваете таблицы).

Вы также должны действительно использовать SQL Profiler - монитор SQL: StmtStarting и SQL: StmtCompleted события - которые будут показывать вам статистику того, сколько времени занимает каждый оператор выполнить (StmtCompleted является основным, который вас интересует).