我已经以多种方式重写了查询,简化了查询,使用了with索引,并尝试从主查询中调用其他存储的proc。查询本身似乎在系统重新编译时(有时除外)在100%的时间内快速运行。当然,如果我在SSMS中执行此操作,它将编译并快速运行。
CREATE PROC[dbo].spLogHatesMe(
@CID[VARCHAR](200),
@LogType VARCHAR(50) = NULL
)
AS
SELECT *
FROM dbo.Log
WHERE CID = @CID
AND LogType = @LogType;
GO
还请注意,日志表在CID和LogType上具有索引。
我希望优化时间与1000-5000微秒范围内的所有其他编译时间相似。不是“ 25913462”,这是我的最后一个持续时间。没有其他查询具有相同类型的问题。
日志表是主要是插入的日志表。对于一项特定任务,我们需要回顾并读取其中一个值。大约每1读20-25个插入。
我正在从查询存储中使用此查询来获取编译时间:
SELECT TOP 100 *
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt ON Qry.query_text_id = Txt.query_text_id
WHERE Qry.is_internal_query=0
ORDER BY Pl.last_compile_start_time desc
有时,SQL Azure将使存储过程内部的简单查询花费很长时间才能运行。经过大量研究,我已将问题归结为查询中的last_optimize_duration ...