如果需要，可以通过SQL Profiler监视SQL查询

你可以使用“每次保存自动生成脚本”，如果你使用管理工作室。 这当然不是日志。 检查一下是否对你有用。；）

[因为这个问题可能会作为一个重复的问题结束。]

如果SQL Server还没有重新启动(并且计划还没有被清除等等)，您可能能够在计划缓存中找到该查询。

SELECT t.[text]
FROM sys.dm_exec_cached_plans AS p
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%';

如果你因为Management Studio崩溃而丢失了文件，你可以在这里找到恢复文件:

C:\Users\<you>\Documents\SQL Server Management Studio\Backup Files\

否则，你将需要使用其他工具来帮助你保存查询历史，比如Ed Harper的回答中提到的SSMS Tools Pack——尽管它在SQL Server 2012+中不是免费的。或者您可以设置一些轻量级跟踪过滤您的登录名或主机名(但请使用服务器端跟踪，而不是Profiler)。

正如@Nenad-Zivkovic评论的那样，加入sys可能会有帮助。Dm_exec_query_stats和last_execution_time排序:

SELECT t.[text], s.last_execution_time
FROM sys.dm_exec_cached_plans AS p
INNER JOIN sys.dm_exec_query_stats AS s
   ON p.plan_handle = s.plan_handle
CROSS APPLY sys.dm_exec_sql_text(p.plan_handle) AS t
WHERE t.[text] LIKE N'%something unique about your query%'
ORDER BY s.last_execution_time DESC;

正如其他人所指出的，您可以使用SQL Profiler，但也可以通过sp_trace_*系统存储过程来利用它的功能。例如，这个SQL片段将(至少在2000年;我认为这对SQL 2008是一样的，但你必须仔细检查)捕获RPC:Completed和SQL:BatchCompleted事件的所有查询需要超过10秒运行，并将输出保存到一个跟踪文件，您可以在稍后的日期在SQL分析器中打开:

DECLARE @TraceID INT
DECLARE @ON BIT
DECLARE @RetVal INT
SET @ON = 1

exec @RetVal = sp_trace_create @TraceID OUTPUT, 2, N'Y:\TraceFile.trc'
print 'This trace is Trace ID = ' + CAST(@TraceID AS NVARCHAR)
print 'Return value = ' + CAST(@RetVal AS NVARCHAR)
-- 10 = RPC:Completed
exec sp_trace_setevent @TraceID, 10, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 10, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 10, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 10, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 10, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 10, 15, @ON        -- EndTime

-- 12 = SQL:BatchCompleted
exec sp_trace_setevent @TraceID, 12, 1, @ON     -- Textdata
exec sp_trace_setevent @TraceID, 12, 3, @ON     -- DatabaseID
exec sp_trace_setevent @TraceID, 12, 12, @ON        -- SPID
exec sp_trace_setevent @TraceID, 12, 13, @ON        -- Duration
exec sp_trace_setevent @TraceID, 12, 14, @ON        -- StartTime
exec sp_trace_setevent @TraceID, 12, 15, @ON        -- EndTime

-- Filter for duration [column 13] greater than [operation 2] 10 seconds (= 10,000ms)
declare @duration bigint
set @duration = 10000
exec sp_trace_setfilter @TraceID, 13, 0, 2, @duration

您可以从Books Online中找到每个跟踪事件、列等的ID;只需搜索sp_trace_create、sp_trace_setevent和sp_trace_setfiler sppros即可。然后，您可以像下面这样控制跟踪:

exec sp_trace_setstatus 15, 0       -- Stop the trace
exec sp_trace_setstatus 15, 1       -- Start the trace
exec sp_trace_setstatus 15, 2       -- Close the trace file and delete the trace settings

.．.其中'15'是跟踪ID(如上面的第一个脚本所删除的sp_trace_create所报告的)。

您可以查看哪些跟踪正在运行:

select * from ::fn_trace_getinfo(default)

我唯一要谨慎说的是——我不知道这会给你的系统带来多少负载;它将添加一些，但“一些”的大小可能取决于您的服务器有多忙。

下面的SQL查询可以显示简单的查询日志:

SELECT last_execution_time, text
FROM sys.dm_exec_query_stats stats
CROSS APPLY sys.dm_exec_sql_text(stats.sql_handle) 
ORDER BY last_execution_time

下图是它的样子:

并且，下面的SQL查询可以显示简单的事务查询日志:

SELECT Operation, [Begin Time], [End Time] 
FROM fn_dblog(NULL,NULL)

下图是它的样子:

此外，我还不知道SQL查询将简单查询日志和简单事务查询日志显示在一起。

如果需要，可以通过SQL Profiler监视SQL查询