是否可以在SQL Server中優化ShowPlan XML

我有一個相當複雜的查詢，一旦SQL服務器建立查詢計劃（令人滿意），就會在一秒鐘內運行。但是，查詢第一次根據探查器運行事件ShowPlanXML需要大約14秒（不令人滿意）。是否可以在SQL Server中優化ShowPlan XML

有沒有什麼辦法來優化ShowPlanXML，以便它第一次運行它會更快完成？

或者我會創建一個計劃指南？

對於這裏的信息是SQL查詢（如NHibernate的生成）：

SELECT top 20 this_.UserId as UserId55_0_, this_.User_Version as User2_55_0_, this_.User_ApplicationId as User3_55_0_, this_.User_DeletedOn as User4_55_0_, this_.User_CreatedOn as User5_55_0_, this_.User_ModifiedOn as User6_55_0_, this_.User_CreatedById as User7_55_0_, this_.User_CreatedByName as User8_55_0_, this_.User_ModifiedById as User9_55_0_, this_.User_ModifiedByName as User10_55_0_, this_.User_Name as User11_55_0_, this_.User_ExternalId as User12_55_0_, this_.User_DynamicFields as User13_55_0_, 
this_.User_FirstName as User14_55_0_, this_.User_LastName as User15_55_0_, this_.User_Prefix as User16_55_0_, this_.User_Gender as User17_55_0_, this_.User_Language as 
User18_55_0_, this_.User_Code as User19_55_0_, this_.User_Nationality as User20_55_0_, this_.User_FirstLanguage as User21_55_0_, this_.User_DrivingLicence as User22_55_0_, 
this_.User_Category as User23_55_0_, this_.User_UserStatus as User24_55_0_, this_.User_UserType as User25_55_0_, this_.User_WorkPhone as User26_55_0_, this_.User_MobilePhone as 
User27_55_0_, this_.User_Fax as User28_55_0_, this_.User_Mail as User29_55_0_, this_.User_Login as User30_55_0_, this_.User_Password as User31_55_0_, this_.User_BornOn as 
User32_55_0_, this_.User_StartedOn as User33_55_0_, this_.User_FinishedOn as User34_55_0_, this_.User_Address as User35_55_0_, this_.User_PostalCode as User36_55_0_, 
this_.User_City as User37_55_0_, this_.User_Country as User38_55_0_, this_.User_PositionTitle as User39_55_0_, this_.User_Comments as User40_55_0_, this_.User_OptionalField1 as 
User41_55_0_, this_.User_OptionalField2 as User42_55_0_, this_.User_OptionalField3 as User43_55_0_, this_.User_PasswordConsecutiveFailedAttempts as User44_55_0_, 
this_.User_PasswordModificationDate as User45_55_0_, this_.User_WrongPasswordAttemptDate as User46_55_0_, this_.User_PictureUrl as User47_55_0_, this_.User_PasswordModificationStatus as User48_55_0_, this_.User_SecretQuestionConsecutiveFailedAttempts as User49_55_0_, this_.User_PlatformMailTransfer as User50_55_0_, this_.User_TimeZoneId as User51_55_0_, this_.User_ConnectionState as User52_55_0_, this_.User_LastConnectionId as User53_55_0_, this_.User_TotalPercentRealized as User54_55_0_ 
FROM Dir_User this_ 
WHERE this_.UserId in (
     SELECT distinct this_0_.UserId as y0_ 
     FROM Dir_User this_0_ inner join Dir_UserDynamicGroup dynamicgro3_ on this_0_.UserId=dynamicgro3_.UsDy_UserId 
     inner join Dir_Group dynamicgro1_ on dynamicgro3_.UsDy_DynamicGroupId=dynamicgro1_.GroupId 
     WHERE dynamicgro1_.GroupId = (51904517) 
     and this_0_.User_ApplicationId = 65536 
     and this_0_.User_DeletedOn is null 
     and this_0_.UserId in (
      SELECT distinct this_0_0_.TargetUserId as y0_ 
      FROM Dir_UserGroupMember this_0_0_ 
      WHERE this_0_0_.OwnerUserId = 7341195 
      and ((this_0_0_.Scope & 139280) != 0 or ((this_0_0_.Scope & 139280) != 0 
      and this_0_0_.GroupId = this_0_0_.SubGroupId)))) 
      ORDER BY this_.User_Name asc

來源

2012-04-30 Tom Carter

你是說這個查詢需要很長時間才能執行第一次執行，因爲編譯或字面showplan採取那麼長？如果是後者，我說不要擔心;您將不會在您的應用程序中運行查詢並返回showplan結果。這是一個診斷工具，僅用於調試和故障排除。 –

它是前者 - 根據探查器，ShowPlanXml事件每次在SSMS中執行查詢時都會運行。第一次需要14秒才能編譯，然後從緩存中訪問該計劃。如果我運行DBCC DROPCLEANBUFFERS緩存被清除，該計劃被重新計算再次採取14秒 –

根據這個（http://msdn.microsoft.com/en-us/library/ms188661.aspx），該事件觸發每次查詢運行並引用「包含此事件類的跟蹤可能會導致顯着的性能開銷」。如果你想看看你的查詢的性能，我會建議看看DMVs，即sys.dm_exec_query_stats和它的兄弟。 –

該節目計劃探查事件對SQL服務器的性能有顯著影響（見sqlserver.query_post_execution_showplan Performance Impact）。如果要準確表示編譯存儲過程所花費的時間，則應使用其他方法。

您應該能夠通過直接查看計劃緩存來確定計劃花費多少時間進行編譯，請參閱Identifying High Compile Time Statements from the Plan Cache。

不幸的是，我不知道有許多方法可以減少SQL Server查詢的編譯時間，而不僅僅是簡化查詢的複雜度。試圖通過計劃緩存降低計劃編譯的頻率是提高性能的標準方法。

來源

2013-06-04 15:06:40 Justin

是否可以在SQL Server中優化ShowPlan XML

回答

相關問題