How to measure the server execution time of SQL

Question

How to measure the server execution time of SQL

博雄胡 785

I want to know how long it takes for the server to complete the SQL after it is sent to the server, so that I can determine whether the time consumed when the program executes it is mainly in SQL Server, the network, or the backend/frontend program.

0 comments

Answer accepted by question author

Erland Sommarskog 138.5K MVP Volunteer Moderator

For quick thing, the easiest to do is:

SET STATISTICS TIME ON
-- Statement goes here
SET STATISTICS TIME OFF

However, this is only convenient if you have a single statement, since this gives you data after each statement. On the other hand, you get both duration and CPU time.

For multiple statements, for instance a stored procedure, what I typically do is:

DECLARE @d2 datetime2(3) = sysdatetime()
EXEC some_sp
PRINT concat('It took ', datediff(ms, @d2, sysdatetime()), ' ms.'

If you want also CPU or you want timings per statement to see which statement that took most time etc, you can use Lee Tudors sp_sqltrace which I host on my web site.

Pothula Ravi 5 Reputation points

2026-10-21T11:21:31.6733333+00:00

One can check the Server Log files, IN/Out of SQL executions in SQL Engine itself...
博雄胡 785 Reputation points

2026-10-21T12:51:25.3866667+00:00

Thank you. I have been using these two methods for the past few years, but I don't think either of them isolates the network communication time. In my current case, which is a single-table query with no conditions, the time measured using these two methods was 17793 ms, but the ASYNC_NETWORK_IO from querying sys.dm_exec_session_wait_stats was 17770 ms.

Do you know about the "Time Statistics" feature in the "Include Client Statistics" option in SSMS? I had a rough understanding of it in the past, but now I've realized that my previous understanding was incorrect. I'm now very curious about its precise meaning.
Erland Sommarskog 138.5K Reputation points MVP Volunteer Moderator

2026-10-21T14:55:41.4933333+00:00

The way I usually deal with that situation is to use SELECT INTO #temp or similar technique to get the client out of the equation. If you are returning a large result set to the client, the client's time to process set the result set will affect the execution time. True, if you write data to a temp table, you instead get the overhead for writing to the temp table, but that is typically lower. What is worse, is that there are some things the optimize only considers for pure SELECT statements, but not for SELECT INTO or INSERT.

Trying to work something from the Client Network Statistics sounds precarious to me, but to be honest I've never tried. I think you just as well could record wait_time_ms for ASYNC_NETWORK_IO before and after the query, if you want to get an idea of the time that SQL Server spent on the operation.

1 additional answer

Your answer

Pothula Ravi 5 Reputation points

2026-10-21T11:21:31.6733333+00:00

One can check the Server Log files, IN/Out of SQL executions in SQL Engine itself...
博雄胡 785 Reputation points

2026-10-21T12:51:25.3866667+00:00

Thank you. I have been using these two methods for the past few years, but I don't think either of them isolates the network communication time. In my current case, which is a single-table query with no conditions, the time measured using these two methods was 17793 ms, but the ASYNC_NETWORK_IO from querying sys.dm_exec_session_wait_stats was 17770 ms.

Do you know about the "Time Statistics" feature in the "Include Client Statistics" option in SSMS? I had a rough understanding of it in the past, but now I've realized that my previous understanding was incorrect. I'm now very curious about its precise meaning.
Erland Sommarskog 138.5K Reputation points MVP Volunteer Moderator

2026-10-21T14:55:41.4933333+00:00

The way I usually deal with that situation is to use SELECT INTO #temp or similar technique to get the client out of the equation. If you are returning a large result set to the client, the client's time to process set the result set will affect the execution time. True, if you write data to a temp table, you instead get the overhead for writing to the temp table, but that is typically lower. What is worse, is that there are some things the optimize only considers for pure SELECT statements, but not for SELECT INTO or INSERT.

Trying to work something from the Client Network Statistics sounds precarious to me, but to be honest I've never tried. I think you just as well could record wait_time_ms for ASYNC_NETWORK_IO before and after the query, if you want to get an idea of the time that SQL Server spent on the operation.

Answer 1

To measure only the time spent on SQL Server after the query reaches the server, use SET STATISTICS TIME ON when running the query. This reports server-side CPU time and elapsed time, which helps separate SQL Server execution from network latency or application processing time.

SET STATISTICS TIME ON
<YourQuery>
SET STATISTICS TIME OFF

For a fuller picture, also enable SET STATISTICS IO ON if needed:

SET STATISTICS TIME ON
SET STATISTICS IO ON
<YourQuery>
SET STATISTICS IO OFF
SET STATISTICS TIME OFF

In SSMS, the reported values appear in Messages. This lets comparison focus on how long the query ran on the server rather than end-to-end program time.

Another server-focused method is to capture query duration with Extended Events using events such as SQL:StmtCompleted, SQL:BatchCompleted, or RPC:Completed.

If an actual execution plan can be collected in SSMS:

Turn on Include Actual Execution Plan.
Run the query.
In Execution plan, select the left-most operator.
In Properties, expand QueryTimeStats.
Check ElapsedTime and CpuTime.

To compare with application-side time:

If application time is much higher than SQL Server elapsed time, the extra time is likely in the network or application processing.
ODBC applications can also inspect driver metrics:
- msExecutionTime: total driver processing time, including waiting for server replies.
- msNetworkServerTime: time spent waiting for replies from the server.

This separation helps determine whether the delay is mainly in SQL Server execution, network transit, or client/backend/frontend processing.