Mida el tiempo que lleva ejecutar una consulta t-sql


156

Tengo dos consultas t-sql con SqlServer 2005. ¿Cómo puedo medir el tiempo que tarda cada una en ejecutarse?

Usar mi cronómetro no es suficiente.


2
¿Está utilizando Sql Server Management Studio? Generalmente muestra el tiempo transcurrido para cada consulta, aunque solo con una segunda resolución. También vea esta pregunta relacionada: stackoverflow.com/questions/8247587/…
mellamokb

Respuestas:


174

Un enfoque simplista para medir el "tiempo transcurrido" entre eventos es tomar la fecha y hora actuales.

En SQL Server Management Studio

SELECT GETDATE();
SELECT /* query one */ 1 ;
SELECT GETDATE();
SELECT /* query two */ 2 ; 
SELECT GETDATE(); 

Para calcular los tiempos transcurridos, puede tomar esos valores de fecha en variables y usar la función DATEDIFF:

DECLARE @t1 DATETIME;
DECLARE @t2 DATETIME;

SET @t1 = GETDATE();
SELECT /* query one */ 1 ;
SET @t2 = GETDATE();
SELECT DATEDIFF(millisecond,@t1,@t2) AS elapsed_ms;

SET @t1 = GETDATE();
SELECT /* query two */ 2 ;
SET @t2 = GETDATE();
SELECT DATEDIFF(millisecond,@t1,@t2) AS elapsed_ms;

Ese es solo un enfoque. También puede obtener los tiempos transcurridos para las consultas con SQL Profiler.


Busqué un documento de Sql Profiler sobre cómo hacer esto, pero no pude encontrar un documento que no requiriera horas de lectura. ¿Me puede recomendar un enlace "Profiler for Dummies"?
TheMoot

@TheMoot Sé que llego tarde, pero los enlaces de MSDN son perfectos para sus necesidades "[Asunto] para Dummies" :). Intente echar un vistazo a esto Cómo: Usar el Analizador de SQL
John Odom

¿Alguien más ha tenido problemas con el uso de esto en sql management studio? Lo agregué a un conjunto de aproximadamente 15 consultas en un procedimiento almacenado para realizar pruebas y lleva demasiado tiempo ejecutarlo. Lo cancelé a los 7 minutos y todos los temporizadores sumaron solo 2 minutos. Por lo tanto, creo que hay algún problema de devolución de caché de texto o tal vez lleva demasiado tiempo calcular todos los fechados para tantos.
MH

2
@Hanoncs: se usa una pequeña cantidad de tiempo para evaluar GETDATE () y asignar el resultado a una variable, y una pequeña cantidad de tiempo para evaluar DATEDIFF () y devolver el resultado. El enfoque simplista que propuse fue obtener una medición aproximada para consultas singleton. No recomendaría usar este enfoque dentro de un ciclo cerrado en un procedimiento almacenado. Si tuviera una serie de consultas en un procedimiento almacenado, podría usar este enfoque para agregar algún resultado de depuración en algunos puntos juiciosos, agregando una columna discriminadora para poder saber qué línea en el procedimiento emitió qué resultado.
spencer7593

1
Por lo general, me quedo SET @t1 = GETDATE();en la parte superior de mi consulta y luego pego en SET @t2 = GETDATE();SELECT 'NOTE 1',DATEDIFF(millisecond,@t1,@t2) AS elapsed_ms;SET @t1 = GETDATE();puntos juiciosos dentro de la consulta (editando "NOTA 1" adecuadamente). Tratar las selecciones como puntos de interrupción en lugar de mediciones es semánticamente idéntico a su enfoque (aunque el conjunto final en @ t1 es falso, y esto supone que todas las consultas deben medirse). Esto es puramente una optimización mental / de escritura (una pasta por punto de interrupción, en lugar de dos pastas por consulta).
Brian

251

Si desea una medición más precisa que la respuesta anterior:

set statistics time on 

-- Query 1 goes here

-- Query 2 goes here

set statistics time off

Los resultados estarán en la ventana Mensajes .

Actualización (29/07/2015):

Por solicitud popular, he escrito un fragmento de código que puede usar para cronometrar la ejecución de un procedimiento almacenado completo, en lugar de sus componentes. Aunque esto solo devuelve el tiempo que tomó la última ejecución, hay estadísticas adicionales devueltas sys.dm_exec_procedure_statsque también pueden ser valiosas:

-- Use the last_elapsed_time from sys.dm_exec_procedure_stats
-- to time an entire stored procedure.

-- Set the following variables to the name of the stored proc
-- for which which you would like run duration info
DECLARE @DbName NVARCHAR(128);
DECLARE @SchemaName SYSNAME;
DECLARE @ProcName SYSNAME=N'TestProc';

SELECT CONVERT(TIME(3),DATEADD(ms,ROUND(last_elapsed_time/1000.0,0),0)) 
       AS LastExecutionTime
FROM sys.dm_exec_procedure_stats
WHERE OBJECT_NAME(object_id,database_id)=@ProcName AND
      (OBJECT_SCHEMA_NAME(object_id,database_id)=@SchemaName OR @SchemaName IS NULL) AND
      (DB_NAME(database_id)=@DbName OR @DbName IS NULL)

2
Solo una nota de que esta función no está disponible si su acceso a la base de datos es de solo lectura. To use SET STATISTICS TIME, users must have the appropriate permissions to execute the Transact-SQL statement. The SHOWPLAN permission is not required. de: technet.microsoft.com/en-us/library/ms190287.aspx
Rob

55
¿Hay alguna manera de ver todo el tiempo que un procedimiento almacenado necesita ejecutarse? En este momento veo muchas mediciones individuales.
Novato

2
@Rookian, agregué un código a la respuesta para ayudarte con eso.
Michael Goldshteyn

17
DECLARE @StartTime datetime
DECLARE @EndTime datetime
SELECT @StartTime=GETDATE() 

 -- Write Your Query


SELECT @EndTime=GETDATE()

--This will return execution time of your query
SELECT DATEDIFF(MS,@StartTime,@EndTime) AS [Duration in millisecs]

También puedes ver esta solución


9
Eso le da el tiempo en nanosegundos. Los milisegundos serían DATEDIFF (MS, @ StartTime, @ EndTime)
d512

11

Otra forma es usar una característica incorporada de SQL Server llamada a la Client Statisticsque se puede acceder a través de Menú> Consulta> Incluir estadísticas del cliente .

Puede ejecutar cada consulta en una ventana de consulta separada y comparar los resultados que se dan en la Client Statisticspestaña junto a la Messagespestaña.

Por ejemplo, en la imagen a continuación, muestra que el tiempo promedio transcurrido para obtener la respuesta del servidor para una de mis consultas es de 39 milisegundos.

Resultado

Puede leer las 3 formas de adquirir tiempo de ejecución aquí . Es posible que incluso necesite mostrar Estimated Execution Plan ctrlLpara una mayor investigación sobre su consulta.


7

¡aún mejor, esto medirá el promedio de n iteraciones de su consulta! Genial para una lectura más precisa.

declare @tTOTAL int = 0
declare @i integer = 0
declare @itrs integer = 100

while @i < @itrs
begin
declare @t0 datetime = GETDATE()

--your query here

declare @t1 datetime = GETDATE()

set @tTotal = @tTotal + DATEDIFF(MICROSECOND,@t0,@t1)

set @i = @i + 1
end

select @tTotal/@itrs

44
He cambiado la MICROSECONDa MILLISECONDy para borrar la memoria caché cada vez que me inserta siguiendo líneas entre beginy declare @t0 ...: CHECKPOINT; DBCC DROPCLEANBUFFERS; DBCC FREEPROCCACHE;. Funciona como encanto y exactamente lo que estaba buscando. +1
Daniel Z.

1
He estado usando su fragmento para medir ajustes de rendimiento incrementales en un procedimiento almacenado, ¡muy hábil!
JayJay

Gracias a los dos. He estado haciendo sql durante mucho tiempo, es un lenguaje peculiar. Pero una vez que sabes lo que son las torceduras y cómo hacer girar a su ventaja, así que ayuda a una gran cantidad XD
HumbleWebDev

3

Haga clic en el icono de Estadísticas para mostrar y luego ejecutar la consulta para obtener los tiempos y saber qué tan eficiente es su consulta

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.