SSMS execution time queries besides SET STATISTICS When I run my query, it prints multiple execution times instead of just one. I only want one so what should I use instead of SET STATISTICS?

SET STATISTICS TIME ON
DECLARE @firstNum INT, @secondNum INT, @thirdNum INT, @evenSum INT
SET @firstNum = 1
SET @secondNum = 2
set @thirdNum = 2
SET @evenSum = 2
WHILE (@thirdNum &lt;= 4000000)
BEGIN
    SET @thirdNum = @firstNum + @secondNum
    SET @firstNum = @secondNum
    SET @secondNum = @thirdNum
    IF (@thirdNum % 2) = 0
    SET @evenSum += @thirdNum
END
PRINT 'Answer = ' + CONVERT(VARCHAR, @evenSum)
SET STATISTICS TIME OFF


It prints this like a hundred times:

SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
In the "Query" menu in SSMS there is an option "Include Client Statistics" that you can look at.

There is no TSQL command like SET STATISTICS that prints out cumulative stats per batch.

You could of course just do

DECLARE @StartTime DATETIME2 = SYSUTCDATETIME()

--Your code here 

SELECT DATEDIFF(NANOSECOND, @StartTime, SYSUTCDATETIME())


But on my desktop the code runs far too quickly for the resolution of SYSUTCDATETIME() so most of the time it returns 0. 

If you just want to know that the code runs "fast enough" to likely not need any performance tuning this may be sufficient.

For a higher resolution option you could get the value of cpu_ticks in sys.dm_os_sys_info before and after execution and try and translate this back to clock time (e.g. by getting the diff and dividing by 3,000 on a 3GHZ processor to get μs) but this may not be reliable.

You could also wrap the code to test into a temporary stored procedure and look at the stats collected for that

CREATE PROC #P AS
BEGIN
YourCodeHere:
END

GO

EXEC #P

SELECT last_execution_time,
       execution_count,
       total_worker_time  AS [total_worker_time μs],
       total_physical_reads,
       total_logical_writes,
       total_logical_reads,
       total_elapsed_time AS [total_worker_time μs]
FROM   tempdb.sys.dm_exec_procedure_stats
WHERE  object_id = OBJECT_ID('tempdb..#P') 


But probably the easiest way of getting useful timings for the original code is simply to run it in a loop for a million times and time the overall duration of that - so that any inaccuracies caused by the resolution of SYSUTCDATETIME() average out to become negligible.