我们已将数据库托管在Azure上,并在此数据库上运行存储过程。存储过程一直运行良好,但突然从上周开始出现连接超时错误。
我们的数据库大小为14 GB,通常返回2k到20k条记录的存储过程使用Azure DB的S3定价层(50 DTU)。
有趣的是,第一次执行存储过程需要很长时间,大约2-3分钟,这导致了超时。后续的执行速度很快(可能缓存了执行计划)。
当我在具有8GB RAM、Win10配置的机器上以相同数量的记录在同一数据库上运行时,它只需15秒即可完成。
这是我的存储过程:
我们的数据库大小为14 GB,通常返回2k到20k条记录的存储过程使用Azure DB的S3定价层(50 DTU)。
有趣的是,第一次执行存储过程需要很长时间,大约2-3分钟,这导致了超时。后续的执行速度很快(可能缓存了执行计划)。
当我在具有8GB RAM、Win10配置的机器上以相同数量的记录在同一数据库上运行时,它只需15秒即可完成。
这是我的存储过程:
CREATE PROCEDURE [dbo].[PRSP]
@CompanyID INT,
@fromDate DATETIME,
@toDate DATETIME,
@ListMailboxId as MailboxIds Readonly,
@ListConversationType as ConversationTypes Readonly
AS
BEGIN
SET NOCOUNT ON;
SELECT
C.ID,
C.MailboxID,
C.Status,
C.CustomerID,
Cust.FName,
Cust.LName,
C.ArrivalDate as ConversationArrivalDate,
C.[ClosureDate],
C.[ConversationType],
M.[From],
M.ArrivalDate as MessageArrivalDate,
M.ID as MessageID
FROM
[Conversation] as C
INNER JOIN
[ConversationHistory] AS CHis ON (CHis.ConversationID = C.ID)
INNER JOIN
[Message] AS M ON (M.ConversationID = C.ID)
INNER JOIN
[Mailbox] AS Mb ON (Mb.ID = C.MailboxID)
INNER JOIN
[Customer] AS Cust ON (Cust.ID = C.CustomerID)
JOIN
@ListConversationType AS convType ON convType.ID = C.[ConversationType]
JOIN
@ListMailboxId AS mailboxIds ON mailboxIds.ID = Mb.ID
WHERE
Mb.CompanyID = @CompanyID
AND ((CHis.CreatedOn > @fromDate
AND CHis.CreatedOn < @toDate
AND CHis.Activity = 1
AND CHis.TagData = '3')
OR (M.ArrivalDate > @fromDate
AND M.ArrivalDate < @toDate))
END
这是执行计划:
请提出您认为需要改进的建议吗?我们是否需要升级定价层?
对于一个14GB的数据库,理想的Azure定价层是什么?
CREATE NONCLUSTERED INDEX [Conv_MailboID_ConvType_CustID] ON [dbo].[Conversation] ( [MailboxID] ASC, [ConversationType] ASC, [CustomerID] ASC ) INCLUDE ( [Status], [ArrivalDate], [ClosureDate])
现在在本地运行只需要1秒钟。我已经在索引中包含了所有那些我在'where'中使用的字段以及我在'select'中使用的字段都被包含在'include'部分作为覆盖。 - Saurabh