使用 Intelligent Insights 針對 Azure SQL Database 效能問題進行疑難排解Troubleshoot Azure SQL Database performance issues with Intelligent Insights

此頁面提供透過 Intelligent Insights 資料庫效能診斷記錄偵測到之 Azure SQL Database 和受控執行個體效能問題的相關資訊。This page provides information on Azure SQL Database and Managed Instance performance issues detected through the Intelligent Insights database performance diagnostics log. 診斷記錄遙測可以串流處理至Azure 監視器記錄Azure 事件中樞Azure 儲存體或協力廠商解決方案, 以取得自訂的 DevOps 警示和報告功能。The diagnostic log telemetry can be streamed to Azure Monitor logs, Azure Event Hubs, Azure Storage, or a third-party solution for custom DevOps alerting and reporting capabilities.

注意

如需使用 Intelligent Insights 進行快速 SQL Database 效能疑難排解的指南,請參閱此文件中的建議的疑難排解流程流程圖。For a quick SQL Database performance troubleshooting guide using Intelligent Insights, see the Recommended troubleshooting flow flowchart in this document.

可偵測的資料庫效能模式Detectable database performance patterns

Intelligent Insights 能根據查詢執行等候時間、錯誤或逾時,自動偵測 SQL Database 與受控執行個體資料庫的效能問題。Intelligent Insights automatically detects performance issues with SQL Database and Managed Instance databases based on query execution wait times, errors, or time-outs. 它會將偵測到的效能模式輸出到診斷記錄。It outputs detected performance patterns to the diagnostics log. 下表摘要說明可偵測的效能模式。Detectable performance patterns are summarized in the table below.

可偵測的效能模式Detectable performance patterns Azure SQL Database 與彈性集區的描述Description for Azure SQL Database and elastic pools 受控執行個體中資料庫的描述Description for databases in Managed Instance
達到資源限制Reaching resource limits 可用資源 (DTU)、資料庫背景工作執行緒或被監視訂用帳戶上可用之資料庫登入工作階段的使用量已達到限制。Consumption of available resources (DTUs), database worker threads, or database login sessions available on the monitored subscription has reached limits. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. CPU 資源使用量已達到受控執行個體限制。Consumption of CPU resources is reaching Managed Instance limits. 這會影響資料庫效能。This is affecting the database performance.
工作負載增加Workload increase 偵測到工作負載增加或資料庫上工作負載的持續累積。Workload increase or continuous accumulation of workload on the database was detected. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 偵測到工作負載增加。Workload increase has been detected. 這會影響資料庫效能。This is affecting the database performance.
記憶體壓力Memory pressure 要求記憶體授與的背景工作角色必須針對記憶體配置等待就統計而言明顯增加的時間長度。Workers that requested memory grants have to wait for memory allocations for statistically significant amounts of time. 或是存在要求記憶體授與之背景工作角色的持續累積。Or an increased accumulation of workers that requested memory grants exists. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 要求記憶體授與的背景工作角色,在統計上來說花了很長的時間等待記憶體配置。Workers that have requested memory grants are waiting for memory allocations for a statistically significant amount of time. 這會影響資料庫效能。This is affecting the database performance.
鎖定Locking 偵測到過多的資料庫鎖定,這會影響 SQL Database 效能。Excessive database locking was detected affecting the SQL Database performance. 偵測到過多的資料庫鎖定,這會影響資料庫效能。Excessive database locking was detected affecting the database performance.
MAXDOP 增加Increased MAXDOP 平行處理原則的最大程度 (MAXDOP) 選項已變更,因而影響查詢執行效率。The maximum degree of parallelism option (MAXDOP) has changed affecting the query execution efficiency. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 平行處理原則的最大程度 (MAXDOP) 選項已變更,因而影響查詢執行效率。The maximum degree of parallelism option (MAXDOP) has changed affecting the query execution efficiency. 這會影響資料庫效能。This is affecting the database performance.
頁面閂鎖爭用Pagelatch contention 多個執行緒同時嘗試存取相同的記憶體內資料緩衝區分頁,因而導致等候時間增加,且造成分頁閂鎖爭用。Multiple threads are concurrently attempting to access the same in-memory data buffer pages resulting in increased wait times and causing pagelatch contention. 這會影響 SQL 資料庫的效能。This is affecting the SQL database the performance. 多個執行緒同時嘗試存取相同的記憶體內資料緩衝區分頁,因而導致等候時間增加,且造成分頁閂鎖爭用。Multiple threads are concurrently attempting to access the same in-memory data buffer pages resulting in increased wait times and causing pagelatch contention. 這會影響資料庫的效能。This is affecting database the performance.
遺漏索引Missing Index 偵測到遺漏索引,這會影響 SQL 資料庫效能。Missing index was detected affecting the SQL database performance. 偵測到遺漏索引,這會影響資料庫效能。Missing index was detected affecting the database performance.
新查詢New Query 偵測到新查詢,這會影響整體 SQL Database 效能。New query was detected affecting the overall SQL Database performance. 偵測到新查詢,這會影響整體資料庫效能。New query was detected affecting the overall database performance.
增加的等候統計資料Increased Wait Statistic 偵測到增加的資料庫等候時間,這會影響 SQL 資料庫效能。Increased database wait times were detected affecting the SQL database performance. 偵測到增加的資料庫等候時間,這會影響資料庫效能。Increased database wait times were detected affecting the database performance.
TempDB 爭用TempDB Contention 多個執行緒嘗試存取相同的 TempDB 資源,因而造成瓶頸。Multiple threads are trying to access the same TempDB resource causing a bottleneck. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 多個執行緒嘗試存取相同的 TempDB 資源,因而造成瓶頸。Multiple threads are trying to access the same TempDB resource causing a bottleneck. 這會影響資料庫效能。This is affecting the database performance.
彈性集區 DTU 不足Elastic pool DTU shortage 彈性集區中的可用 eDTU 不足,因而影響 SQL Database 效能。Shortage of available eDTUs in the elastic pool is affecting SQL Database performance. 不適用於受控執行個體,因為它使用 vCore 模型。Not available for Managed Instance as it uses vCore model.
計畫迴歸Plan Regression 偵測到新的計畫或現有計畫中的工作負載變更。New plan, or a change in the workload of an existing plan was detected. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 偵測到新的計畫或現有計畫中的工作負載變更。New plan, or a change in the workload of an existing plan was detected. 這會影響資料庫效能。This is affecting the database performance.
資料庫範圍組態值變更Database-scoped configuration value change 偵測到 SQL Database 上的設定變更,這會影響資料庫效能。Configuration change on the SQL Database was detected affecting the database performance. 偵測到資料庫上的設定變更,這會影響資料庫效能。Configuration change on the database was detected affecting the database performance.
用戶端執行速度太慢Slow client 緩慢的應用程式用戶端無法以夠快的速度取用來自資料庫的輸出。Slow application client is unable to consume output from the database fast enough. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 緩慢的應用程式用戶端無法以夠快的速度取用來自資料庫的輸出。Slow application client is unable to consume output from the database fast enough. 這會影響資料庫效能。This is affecting the database performance.
定價層降級Pricing tier downgrade 定價層降級動作減少了可用資源。Pricing tier downgrade action decreased available resources. 這會影響 SQL Database 效能。This is affecting the SQL Database performance. 定價層降級動作減少了可用資源。Pricing tier downgrade action decreased available resources. 這會影響資料庫效能。This is affecting the database performance.

提示

如需 SQL Database 的持續效能最佳化,請啟用 Azure SQL Database 自動調整For continuous performance optimization of SQL Database, enable Azure SQL Database automatic tuning. 這個獨特的 SQL Database 內建智慧功能,能夠持續監視您的 SQL 資料庫、自動調整索引,以及套用查詢執行計畫更正。This unique feature of SQL Database built-in intelligence continuously monitors your SQL database, automatically tunes indexes, and applies query execution plan corrections.

下一節詳細說明可偵測的效能模式。The following section describes detectable performance patterns in more detail.

達到資源限制Reaching resource limits

發生的情況What is happening

這個可偵測的效能模式結合了與達到可用資源限制、背景工作角色限制及工作階段限制有關的效能問題。This detectable performance pattern combines performance issues that are related to reaching available resource limits, worker limits, and session limits. 偵測到此效能問題之後,診斷記錄的描述欄位就會指出效能問題是否與資源、背景工作角色,或是工作階段限制相關。After this performance issue is detected, a description field of the diagnostics log indicates whether the performance issue is related to resource, worker, or session limits.

SQL Database 上的資源通常是指 DTU 或是 vCore 資源。Resources on SQL Database are typically referred to DTU or vCore resources. 當偵測到導致查詢效能降低的原因是達到所測量的任何資源限制時,就會認定達到資源限制的模式。The pattern of reaching resource limits is recognized when detected query performance degradation is caused by reaching any of the measured resource limits.

工作階段限制資源代表針對 SQL 資料庫的可用並行登入數。The session limits resource denotes the number of available concurrent logins to the SQL database. 當連線到 SQL 資料庫的應用程式已達到針對該資料庫的可用並行登入數時,就會認定此效能模式。This performance pattern is recognized when applications that are connected to the SQL databases have reached the number of available concurrent logins to the database. 當應用程式嘗試使用的工作階段數超出資料庫上可用的工作階段數時,就會影響查詢效能。If applications attempt to use more sessions than are available on a database, the query performance is affected.

達到背景工作角色限制是達到資源限制的特定案例,因為 DTU 或 vCore 使用量中並未計入可用的背景工作角色數。Reaching worker limits is a specific case of reaching resource limits because available workers aren't counted in the DTU or vCore usage. 達到資料庫上的背景工作角色限制會造成資源特定的等候時間增加,因而降低查詢效能。Reaching worker limits on a database can cause the rise of resource-specific wait times, which results in query performance degradation.

疑難排解Troubleshooting

診斷記錄會輸出影響效能和資源耗用量百分比之查詢的查詢雜湊。The diagnostics log outputs query hashes of queries that affected the performance and resource consumption percentages. 您可以使用此資訊作為將資料庫工作負載最佳化的起點。You can use this information as a starting point for optimizing your database workload. 特別是,您可以新增索引來對影響效能降低的查詢進行最佳化。In particular, you can optimize the queries that affect the performance degradation by adding indexes. 或者,您可以透過更加平均的工作負載分佈來對應用程式進行最佳化。Or you can optimize applications with a more even workload distribution. 如果您無法減少工作負載或進行最佳化,請考慮提高 SQL 資料庫訂用帳戶的定價層,以增加可用的資源數量。If you're unable to reduce workloads or make optimizations, consider increasing the pricing tier of your SQL database subscription to increase the amount of resources available.

如果您已達到可用工作階段限制,則可以透過減少資料庫的登入次數來對應用程式進行最佳化。If you have reached the available session limits, you can optimize your applications by reducing the number of logins made to the database. 如果您無法減少應用程式針對資料庫的登入數,請考慮提高資料庫的定價層。If you're unable to reduce the number of logins from your applications to the database, consider increasing the pricing tier of your database. 或者,您可以將資料庫分割並移至多個資料庫,以取得更加平衡的工作負載分佈。Or you can split and move your database into multiple databases for a more balanced workload distribution.

如需更多有關解決工作階段限制的建議,請參閱如何處理 SQL Database 登入次數上限的限制 (英文)。For more suggestions on resolving session limits, see How to deal with the limits of SQL Database maximum logins. 如需伺服器和訂用帳戶層級的限制資訊,請參閱 SQL Database 伺服器上的資源限制概觀See Overview of resource limits on a SQL Database server for information about limits at the server and subscription levels.

工作負載增加Workload Increase

發生的情況What is happening

這個效能模式所識別的是工作負載增加或其更嚴重形式 (即工作負載堆積) 所造成的問題。This performance pattern identifies issues caused by a workload increase or, in its more severe form, a workload pile-up.

這個偵測是透過組合數個計量來進行的。This detection is made through a combination of several metrics. 所測量的基本計量會偵測與過去的工作負載基準相比,工作負載是否增加。The basic metric measured is detecting an increase in workload compared with the past workload baseline. 另一個偵測形式根據的是測量作用中背景工作執行緒是否大幅增加,亦即是否大到足以影響查詢效能。The other form of detection is based on measuring a large increase in active worker threads that is large enough to affect the query performance.

在其更嚴重的形式中,工作負載可能會因 SQL 資料庫無法處理工作負載而持續堆積。In its more severe form, the workload might continuously pile up due to the inability of the SQL database to handle the workload. 結果就是工作負載大小持續成長,也就是工作負載堆積的情況。The result is a continuously growing workload size, which is the workload pile-up condition. 因為此情況,工作負載等候執行的時間將會增加。Due to this condition, the time that the workload waits for execution grows. 此情況為其中一個最嚴重的資料庫效能問題。This condition represents one of the most severe database performance issues. 透過監視中止的背景工作執行緒數目即可偵測到這個問題。This issue is detected through monitoring the increase in the number of aborted worker threads.

疑難排解Troubleshooting

診斷記錄會輸出執行時間增加的查詢數目,以及對工作負載增加影響最大之查詢的查詢雜湊。The diagnostics log outputs the number of queries whose execution has increased and the query hash of the query with the largest contribution to the workload increase. 您可以使用此資訊作為將工作負載最佳化的起點。You can use this information as a starting point for optimizing the workload. 將識別對工作負載增加影響最大的查詢作為起點,將會特別有幫助。The query identified as the largest contributor to the workload increase is especially useful as your starting point.

您也可以考慮將工作負載更平均地分配給資料庫。You might consider distributing the workloads more evenly to the database. 請考慮新增索引以針對影響效能的查詢進行最佳化。Consider optimizing the query that is affecting the performance by adding indexes. 您也可以將工作負載散發至多個資料庫。You also might distribute your workload among multiple databases. 如果這些解決方案都不可行,請考慮提高 SQL 資料庫訂用帳戶的定價層,以增加可用的資源數量。If these solutions aren't possible, consider increasing the pricing tier of your SQL database subscription to increase the amount of resources available.

記憶體壓力Memory Pressure

發生的情況What is happening

這個效能模式表示與過去七天的效能基準相比,目前的資料庫效能降低,原因是記憶體壓力或其更嚴重的形式,亦即有記憶體堆積的情況。This performance pattern indicates degradation in the current database performance caused by memory pressure, or in its more severe form a memory pile-up condition, compared to the past seven-day performance baseline.

記憶體壓力代表一種效能情況,也就是 SQL 資料庫中有大量要求授與記憶體的背景工作執行緒。Memory pressure denotes a performance condition in which there is a large number of worker threads requesting memory grants in the SQL database. 大量的要求會導致高記憶體使用量情況,而 SQL 資料庫將無法有效地將記憶體配置給要求記憶體的所有背景工作角色。The high volume causes a high memory utilization condition in which the SQL database is unable to efficiently allocate memory to all workers that request it. 此問題最常見的原因之一,一方面與可供 SQL 資料庫使用的記憶體量有關。One of the most common reasons for this issue is related to the amount of memory available to the SQL database on one hand. 另一方面的因素,則是因工作負載增加而造成的背景工作執行緒及記憶體壓力提升。On the other hand, an increase in workload causes the increase in worker threads and the memory pressure.

記憶體壓力的更嚴重形式,則是記憶體堆積的情況。The more severe form of memory pressure is the memory pile-up condition. 此情況指出要求記憶體授與的背景工作執行緒數目,比釋放記憶體的查詢還要多。This condition indicates that a higher number of worker threads are requesting memory grants than there are queries releasing the memory. 這個要求授與記憶體的背景工作執行緒數目可能也會持續增加 (堆積),因為 SQL 資料庫無法有效率地配置記憶體來滿足需求。This number of worker threads requesting memory grants also might be continuously increasing (piling up) because the SQL database engine is unable to allocate memory efficiently enough to meet the demand. 記憶體堆積情況為其中一個最嚴重的資料庫效能問題。The memory pile-up condition represents one of the most severe database performance issues.

疑難排解Troubleshooting

診斷記錄會輸出記憶體物件存放區詳細資料,其中會將 Clerk (即背景工作執行緒) 標示為高記憶體使用量的最大原因,也會輸出相關的時間戳記。The diagnostics log outputs the memory object store details with the clerk (that is, worker thread) marked as the highest reason for high memory usage and relevant time stamps. 您可以使用此資訊作為疑難排解的基礎。You can use this information as the basis for troubleshooting.

您可以將與具有最高記憶體使用量之 Clerk 相關的查詢最佳化或移除。You can optimize or remove queries related to the clerks with the highest memory usage. 您也可以確定自己不會查詢沒有計畫使用的資料。You also can make sure that you aren't querying data that you don't plan to use. 理想的做法是在您的查詢中一律使用 WHERE 子句。Good practice is to always use a WHERE clause in your queries. 此外,建議您建立非叢集索引來搜尋資料,而不要掃描它。In addition, we recommend that you create nonclustered indexes to seek the data rather than scan it.

您也可以對工作負載進行最佳化,或將它散發至多個資料庫來減少工作負載。You also can reduce the workload by optimizing or distributing it over multiple databases. 或者,您可以將工作負載散發至多個資料庫。Or you can distribute your workload among multiple databases. 如果這些解決方案都不可行,請考慮提高 SQL 資料庫訂用帳戶的定價層,以增加可供資料庫使用的記憶體資源數量。If these solutions aren't possible, consider increasing the pricing tier of your SQL database subscription to increase the amount of memory resources available to the database.

如需其他疑難排解建議,請參閱記憶體授與深思:有許多名稱的神秘 SQL Server 記憶體取用者 (英文)。For additional troubleshooting suggestions, see Memory grants meditation: The mysterious SQL Server memory consumer with many names.

正在鎖定Locking

發生的情況What is happening

這個效能模式表示與過去七天的效能基準相比,目前的資料庫效能降低,其中偵測到過多的資料庫鎖定。This performance pattern indicates degradation in the current database performance in which excessive database locking is detected compared to the past seven-day performance baseline.

在現代化的 RDBMS 中,對於實作多執行緒的系統 (其中會透過儘可能執行多個同時背景工作角色和平行資料庫交易來發揮最大效能) 來說,鎖定是不可或缺的。In modern RDBMS, locking is essential for implementing multithreaded systems in which performance is maximized by running multiple simultaneous workers and parallel database transactions where possible. 此內容中的鎖定係指內建的存取機制,其中只有單一交易能夠以獨佔方式存取所需的資料列、頁面、資料表及檔案,而不會與另一個交易競爭資源。Locking in this context refers to the built-in access mechanism in which only a single transaction can exclusively access the rows, pages, tables, and files that are required and not compete with another transaction for resources. 當鎖定資源來使用的交易已經使用完資源時,就會釋出那些資源上的鎖定,這能允許其他交易存取所需的資源。When the transaction that locked the resources for use is done with them, the lock on those resources is released, which allows other transactions to access required resources. 如需有關鎖定的詳細資訊,請參閱資料庫引擎中的鎖定For more information on locking, see Lock in the database engine.

當 SQL 引擎所執行的交易存取已鎖定使用的資源時,如果等候時間較長,這個等候時間將會導致工作負載執行效能變差。If transactions executed by the SQL engine are waiting for prolonged periods of time to access resources locked for use, this wait time causes the slowdown of the workload execution performance.

疑難排解Troubleshooting

診斷記錄會輸出鎖定詳細資料,料可用來作為疑難排解的基礎。The diagnostics log outputs locking details that you can use as the basis for troubleshooting. 您可以分析系統回報的鎖定查詢 (即導致鎖定效能降低的查詢),然後將它們移除。You can analyze the reported blocking queries, that is, the queries that introduce the locking performance degradation, and remove them. 在某些情況下,您可能可以順利將鎖定查詢最佳化。In some cases, you might be successful in optimizing the blocking queries.

此問題的最簡單且最安全緩和方式就是讓交易簡短,以及減少最耗用資源之查詢的鎖定使用量。The simplest and safest way to mitigate the issue is to keep transactions short and to reduce the lock footprint of the most expensive queries. 您可以將大型的作業批次分成較小的作業。You can break up a large batch of operations into smaller operations. 理想的做法是儘可能提升查詢效率,以減少查詢鎖定使用量。Good practice is to reduce the query lock footprint by making the query as efficient as possible. 請減少大型掃描,因為它們會增加死結的機率,並對整體資料庫效能帶來負面影響。Reduce large scans because they increase chances of deadlocks and adversely affect overall database performance. 針對已識別為會造成鎖定的查詢,您可以建立新的索引,或是將資料行新增至現有索引中來避免資料表掃描。For identified queries that cause locking, you can create new indexes or add columns to the existing index to avoid the table scans.

如需更多建議,請參閱如何解決 SQL Server 中鎖定擴大所造成的鎖定問題 (英文)。For more suggestions, see How to resolve blocking problems that are caused by lock escalation in SQL Server.

MAXDOP 增加Increased MAXDOP

發生的情況What is happening

這個可偵測的效能模式表示所選查詢執行計畫的平行處理程度超出其應有程度的情況。This detectable performance pattern indicates a condition in which a chosen query execution plan was parallelized more than it should have been. SQL Database 查詢最佳化工具會藉由以平行方式執行查詢來儘可能加快速度,以提升工作負載效能。The SQL Database query optimizer can enhance the workload performance by executing queries in parallel to speed up things where possible. 在某些情況下,相較於使用較少平行背景工作角色 (或在某些情況下相較於單一背景工作處理序) 來執行相同的查詢,處理查詢的平行背景工作角色會花費更多的時間等候彼此進行同步並合併結果。In some cases, parallel workers processing a query spend more time waiting on each other to synchronize and merge results compared to executing the same query with fewer parallel workers, or even in some cases compared to a single worker thread.

專家系統會以基準期間作為比較,對目前的資料庫效能進行分析。The expert system analyzes the current database performance compared to the baseline period. 它會判斷先前執行的查詢是否因為查詢執行計畫的平行處理程度超出其應有程度,而使其執行的速度比先前還慢。It determines if a previously running query is running slower than before because the query execution plan is more parallelized than it should be.

SQL Database 上的 MAXDOP 伺服器設定選項可用來控制能夠使用多少個 CPU 核心來平行執行相同的查詢。The MAXDOP server configuration option on SQL Database is used to control how many CPU cores can be used to execute the same query in parallel.

疑難排解Troubleshooting

診斷記錄會輸出執行持續時間因平行處理程度大於應有程度而增加之查詢的相關查詢雜湊。The diagnostics log outputs query hashes related to queries for which the duration of execution increased because they were parallelized more than they should have been. 此記錄也會輸出 CXP 等候時間。The log also outputs CXP wait times. 此時間代表單一組合管理/協調者執行緒 (執行緒 0) 在合併結果並繼續進行之前,等候所有其他執行緒完成工作的時間。This time represents the time a single organizer/coordinator thread (thread 0) is waiting for all other threads to finish before merging the results and moving ahead. 此外,診斷記錄也會輸出效能不佳之查詢整體等候執行的等候時間。In addition, the diagnostics log outputs the wait times that the poor-performing queries were waiting in execution overall. 您可以使用此資訊作為疑難排解的基礎。You can use this information as the basis for troubleshooting.

首先,請將複雜的查詢最佳化或簡化。First, optimize or simplify complex queries. 理想的做法是將大批作業拆解成較小的作業。Good practice is to break up long batch jobs into smaller ones. 此外,請確定您已建立支援查詢的索引。In addition, ensure that you created indexes to support your queries. 您也可以針對已標示為效能不佳的查詢,手動強制執行平行處理原則的最大程度 (MAXDOP)。You can also manually enforce the maximum degree of parallelism (MAXDOP) for a query that was flagged as poor performing. 若要使用 T-SQL 設定此作業,請參閱設定 MAXDOP 伺服器設定選項To configure this operation by using T-SQL, see Configure the MAXDOP server configuration option.

將 MAXDOP 伺服器設定選項設定為零 (0) 作為預設值時,表示 SQL Database 可以使用所有可用的邏輯 CPU 核心來針對單一查詢執行平行處理執行緒。Setting the MAXDOP server configuration option to zero (0) as a default value denotes that SQL Database can use all available logical CPU cores to parallelize threads for executing a single query. 將 MAXDOP 設定為一 (1) 表示針對單一查詢執行只能使用一個核心。Setting MAXDOP to one (1) denotes that only one core can be used for a single query execution. 實際上,這代表平行處理已關閉。In practical terms, this means that parallelism is turned off. 您可以視每一案例情況、資料庫可用的核心及診斷記錄資訊而定,將 MAXDOP 選項調整成可能可以解決您案例中問題的平行查詢執行核心數。Depending on the case-per-case basis, available cores to the database, and diagnostics log information, you can tune the MAXDOP option to the number of cores used for parallel query execution that might resolve the issue in your case.

頁面閂鎖爭用Pagelatch Contention

發生的情況What is happening

這個效能模式表示與過去七天的工作負載基準相比,目前的資料庫工作負載效能降低,原因是發生頁面閂鎖爭用。This performance pattern indicates the current database workload performance degradation due to pagelatch contention compared to the past seven-day workload baseline.

閂鎖為 SQL Database 用來啟用多執行緒處理的輕量型同步處理機制。Latches are lightweight synchronization mechanisms used by SQL Database to enable multithreading. 它們能保證記憶體內部結構 (包括索引、資料頁面及其他內部結構) 的一致性。They guarantee consistency of in-memory structures that include indices, data pages, and other internal structures.

SQL Database 上有多種可用的閂鎖。There are many types of latches available on the SQL database. 為了簡單起見,系統會使用緩衝區閂鎖來保護緩衝集區中的記憶體內部頁面。For simplicity purposes, buffer latches are used to protect in-memory pages in the buffer pool. 系統會使用 IO 閂鎖來保護尚未載入緩衝集區的頁面。IO latches are used to protect pages not yet loaded into the buffer pool. 每次將資料寫入到緩衝集區中的頁面或從該頁面讀取資料時,背景工作執行緒都必須先取得該頁面的緩衝區閂鎖。Whenever data is written to or read from a page in the buffer pool, a worker thread needs to acquire a buffer latch for the page first. 每次背景工作執行緒嘗試存取記憶體內緩衝集區中尚未提供的頁面時,都會發出 IO 要求以從儲存體載入所需的資訊。Whenever a worker thread attempts to access a page that isn't already available in the in-memory buffer pool, an IO request is made to load the required information from the storage. 這些事件代表的是一種更嚴重的效能降低情況。This sequence of events indicates a more severe form of performance degradation.

當多個執行緒同時嘗試在相同的記憶體內結構上取得閂鎖時,就會發生頁面閂鎖爭用,因而導致等候執行查詢的時間增加。Contention on the page latches occurs when multiple threads concurrently attempt to acquire latches on the same in-memory structure, which introduces an increased wait time to query execution. 當必須從儲存體存取資料時,如果發生頁面閂鎖 IO 爭用,這個等候時間甚至會更長。In the case of pagelatch IO contention, when data needs to be accessed from storage, this wait time is even larger. 它可能會大幅影響工作負載效能。It can affect workload performance considerably. 對於等候彼此並競爭多個 CPU 系統上資源的執行緒來說,頁面閂鎖爭用是最常見的情況。Pagelatch contention is the most common scenario of threads waiting on each other and competing for resources on multiple CPU systems.

疑難排解Troubleshooting

診斷記錄會輸出頁面閂鎖爭用的詳細資料。The diagnostics log outputs pagelatch contention details. 您可以使用此資訊作為疑難排解的基礎。You can use this information as the basis for troubleshooting.

由於頁面閂鎖是 SQL Database 的內部控制機制,因此它會自動判斷何時該使用頁面閂鎖。Because a pagelatch is an internal control mechanism of SQL Database, it automatically determines when to use them. 因為閂鎖具有決定性行為,所以應用程式決策 (包括結構描述設計) 會影響頁面閂鎖行為。Application decisions, including schema design, can affect pagelatch behavior due to the deterministic behavior of latches.

其中一個處理閂鎖爭用的方法是使用非循序索引鍵來取代循序索引鍵,以將插入平均分散到整個索引範圍。One method for handling latch contention is to replace a sequential index key with a nonsequential key to evenly distribute inserts across an index range. 通常,在索引中建立前置資料行將可以按比例分配工作負載。Typically, a leading column in the index distributes the workload proportionally. 另一個可考慮的方法是資料表分割。Another method to consider is table partitioning. 使用資料分割資料表上的計算資料行來建立雜湊分割配置,是一個緩和過多閂鎖爭用的常見方法。Creating a hash partitioning scheme with a computed column on a partitioned table is a common approach for mitigating excessive latch contention. 當發生頁面閂鎖 IO 爭用時,導入索引可協助緩和這個效能問題。In the case of pagelatch IO contention, introducing indexes helps to mitigate this performance issue.

如需詳細資訊,請參閱診斷和解決 SQL Server 上的閂鎖爭用 (英文) (PDF 下載)。For more information, see Diagnose and resolve latch contention on SQL Server (PDF download).

遺漏索引Missing Index

發生的情況What is happening

這個效能模式表示與過去七天的基準相比,目前的資料庫工作負載效能降低,原因是遺漏索引。This performance pattern indicates the current database workload performance degradation compared to the past seven-day baseline due to a missing index.

索引可用來提升查詢的效能。An index is used to speed up the performance of queries. 它可藉由減少所需瀏覽或掃描的資料集頁數,加快存取資料表資料的速度。It provides quick access to table data by reducing the number of dataset pages that need to be visited or scanned.

透過這項偵測可識別出造成效能降低的特定查詢,針對這些查詢,建立索引將有助於提升效能。Specific queries that caused performance degradation are identified through this detection for which creating indexes would be beneficial to the performance.

疑難排解Troubleshooting

診斷記錄會輸出已識別為影響工作負載效能之查詢的查詢雜湊。The diagnostics log outputs query hashes for the queries that were identified to affect the workload performance. 您可以針對這些查詢建立索引。You can build indexes for these queries. 您也可以將索引最佳化,或是在不需要的情況下將它們移除。You also can optimize or remove these queries if they aren't required. 理想的效能做法是避免查詢您不使用的資料。A good performance practice is to avoid querying data that you don't use.

提示

您知道 SQL Database 內建的智慧功能可以自動為資料庫管理效能最佳的索引嗎?Did you know that SQL Database built-in intelligence can automatically manage the best-performing indexes for your databases?

如需 SQL Database 的持續效能最佳化,建議您啟用 SQL Database 自動調整For continuous performance optimization of SQL Database, we recommend that you enable SQL Database automatic tuning. 這個獨特的 SQL Database 內建智慧功能,能夠持續監視您的 SQL 資料庫,並自動為資料庫調整及建立索引。This unique feature of SQL Database built-in intelligence continuously monitors your SQL database and automatically tunes and creates indexes for your databases.

新增查詢New Query

發生的情況What is happening

這個效能模式表示偵測到新查詢,而與過去七天效能基準相比,此查詢的效能不佳且影響工作負載效能。This performance pattern indicates that a new query is detected that is performing poorly and affecting the workload performance compared to the seven-day performance baseline.

撰寫效能良好的查詢有時會是相當具有挑戰性的工作。Writing a good-performing query sometimes can be a challenging task. 如需撰寫查詢的詳細資訊,請參閱撰寫 SQL 查詢 (英文)。For more information on writing queries, see Writing SQL queries. 若要對現有查詢效能進行最佳化,請參閱查詢微調To optimize existing query performance, see Query tuning.

疑難排解Troubleshooting

診斷記錄最多會輸出兩個耗用最多 CPU 資源之查詢的資訊,包括其查詢雜湊。The diagnostics log outputs information up to two new most CPU-consuming queries, including their query hashes. 因為偵測到的查詢會影響工作負載效能,您可以將查詢最佳化。Because the detected query affects the workload performance, you can optimize your query. 理想的做法是僅擷取所需的資料。Good practice is to retrieve only data you need to use. 我們也建議使用搭配 WHERE 子句的查詢。We also recommend using queries with a WHERE clause. 我們也建議您將複雜的查詢簡化,並將它們拆解成較小的查詢。We also recommend that you simplify complex queries and break them up into smaller queries. 另一個理想的做法是將大批的查詢拆解成較小批的查詢。Another good practice is to break down large batch queries into smaller batch queries. 通常,緩和此效能問題的理想做法是為新查詢導入索引。Introducing indexes for new queries is typically a good practice to mitigate this performance issue.

請考慮使用 Azure SQL Database 查詢效能深入解析Consider using Azure SQL Database Query Performance Insight.

增加的等候統計資料Increased Wait Statistic

發生的情況What is happening

這個可偵測的效能模式表示與過去七天的工作負載基準相比,工作負載效能降低,其中發現有效能不佳的查詢。This detectable performance pattern indicates a workload performance degradation in which poor-performing queries are identified compared to the past seven-day workload baseline.

在此情況中,系統無法將效能不佳的查詢歸類至任何其他標準的可偵測效能類別,但它偵測到等候統計資料是造成迴歸的原因。In this case, the system can't classify the poor-performing queries under any other standard detectable performance categories, but it detected the wait statistic responsible for the regression. 因此,系統會將那些查詢判斷為具有「增加的等候統計資料」,並同時公開造成迴歸的等候統計資料。Therefore, it considers them as queries with increased wait statistics, where the wait statistic responsible for the regression is also exposed.

疑難排解Troubleshooting

診斷記錄會輸出有關增加之等候時間的詳細資料和受影響查詢之查詢雜湊的資訊。The diagnostics log outputs information on increased wait time details and query hashes of the affected queries.

由於系統無法順利識別出效能不佳查詢的根本原因,因此診斷資訊是進行手動疑難排解的理想起點。Because the system couldn't successfully identify the root cause for the poor-performing queries, the diagnostics information is a good starting point for manual troubleshooting. 您可以對這些查詢的效能進行最佳化。You can optimize the performance of these queries. 理想的做法是僅擷取所需的資料,然後將複雜的查詢簡化並拆解成較小的查詢。A good practice is to fetch only data you need to use and to simplify and break down complex queries into smaller ones.

如需有關將查詢效能最佳化的詳細資訊,請參閱查詢微調For more information on optimizing query performance, see Query tuning.

TempDB 爭用TempDB Contention

發生的情況What is happening

這個可偵測的效能模式表示一種資料庫效能情況,亦即嘗試存取 tempDB 資源的執行緒發生瓶頸。This detectable performance pattern indicates a database performance condition in which a bottleneck of threads trying to access tempDB resources exists. (此情況與 IO 無關)。此效能問題的典型案例就是有數百個並行查詢,這些查詢都建立,使用然後卸除小型 tempDB 資料表。(This condition isn't IO related.) The typical scenario for this performance issue is hundreds of concurrent queries that all create, use, and then drop small tempDB tables. 系統已偵測到使用相同 tempDB 資料表的並行查詢數目就統計而言明顯增加,以致與過去七天效能基準相比,影響資料庫效能。The system detected that the number of concurrent queries using the same tempDB tables increased with sufficient statistical significance to affect database performance compared to the past seven-day performance baseline.

疑難排解Troubleshooting

診斷記錄會輸出 tempDB 爭用的詳細資料。The diagnostics log outputs tempDB contention details. 您可以使用此資訊作為疑難排解的起點。You can use the information as the starting point for troubleshooting. 若要減輕此競爭情形,並提升整體工作負載的輸送量,您可以嘗試兩種方法:您可以停止使用暫存資料表。There are two things you can pursue to alleviate this kind of contention and increase the throughput of the overall workload: You can stop using the temporary tables. 您也可以使用經記憶體最佳化的資料表。You also can use memory-optimized tables.

如需詳細資訊,請參閱經記憶體最佳化的資料表簡介For more information, see Introduction to memory-optimized tables.

彈性集區 DTU 不足Elastic pool DTU shortage

發生的情況What is happening

這個偵測的效能模式表示與過去七天的基準相比,目前的資料庫工作負載效能降低。This detectable performance pattern indicates a degradation in the current database workload performance compared to the past seven-day baseline. 原因是訂用帳戶彈性集區中的可用 DTU 不足。It's due to the shortage of available DTUs in the elastic pool of your subscription.

SQL Database 上的資源通常稱為 DTU 資源,是由 CPU 與 IO (資料和交易記錄 IO) 資源的混合量值所組成。Resources on SQL Database are typically referred to as DTU resources, which consist of a blended measure of CPU and IO (data and transaction log IO) resources. Azure 彈性集區資源可用來作為多個資料庫間共用的可用 eDTU 資源集區,以供進行調整之用。Azure elastic pool resources are used as a pool of available eDTU resources shared between multiple databases for scaling purposes. 當您彈性集區中的可用 eDTU 資源並未大到足以支援集區中的所有資料庫時,系統就會偵測到彈性集區 DTU 不足的效能問題。When available eDTU resources in your elastic pool aren't sufficiently large to support all the databases in the pool, an elastic pool DTU shortage performance issue is detected by the system.

疑難排解Troubleshooting

診斷記錄會輸出彈性集區的相關資訊、列出 DTU 取用量最高的資料庫,以及提供取用量最高之資料庫所使用的集區 DTU 百分比。The diagnostics log outputs information on the elastic pool, lists the top DTU-consuming databases, and provides a percentage of the pool's DTU used by the top-consuming database.

由於這個效能情況與使用彈性集區中相同 eDTU 集區的多個資料庫相關,因此疑難排解步驟會著重在 DTU 取用量最高的資料庫上。Because this performance condition is related to multiple databases using the same pool of eDTUs in the elastic pool, the troubleshooting steps focus on the top DTU-consuming databases. 您可以降低取用量最高之資料庫上的工作負載,包括將那些資料庫上取用量最高的查詢最佳化。You can reduce the workload on the top-consuming databases, which includes optimization of the top-consuming queries on those databases. 您也可以確定自己不會查詢不需要使用的資料。You also can ensure that you aren't querying data that you don't use. 另一個方法是將使用 DTU 取用量最高之資料庫的應用程式最佳化,然後將工作負載重新分散到多個資料庫。Another approach is to optimize applications by using the top DTU-consuming databases and redistribute the workload among multiple databases.

如果您無法將 DTU 取用量最高之資料庫上的目前工作負載降低和最佳化,請考慮提升彈性集區定價層。If reduction and optimization of the current workload on your top DTU-consuming databases aren't possible, consider increasing your elastic pool pricing tier. 這個提升將可增加彈性集區中的可用的 DTU。Such increase results in the increase of the available DTUs in the elastic pool.

計畫迴歸Plan Regression

發生的情況What is happening

這個可偵測的效能模式表示一種情況,亦即 SQL Database 使用次佳的查詢執行計畫。This detectable performance pattern denotes a condition in which SQL Database utilizes a suboptimal query execution plan. 次佳的計畫通常會造成查詢的執行時間增加,這會導致目前及其他查詢的等候時間變長。The suboptimal plan typically causes increased query execution, which leads to longer wait times for the current and other queries.

SQL 資料庫會判斷出查詢執行成本最低的查詢執行計畫。The SQL database determines the query execution plan with the least cost to a query execution. 隨著查詢類型和工作負載發生變更,有時現有的計畫會變得不再有效率,或 SQL Database 可能並未做出理想的評估。As the type of queries and workloads change, sometimes the existing plans are no longer efficient, or perhaps SQL Database didn't make a good assessment. 為了更正這種狀況,您可以手動強制執行查詢執行計畫。As a matter of correction, query execution plans can be manually forced.

這個可偵測的效能模式結合了三種不同的計畫迴歸案例:新計畫迴歸、舊計畫迴歸,以及現有計畫變更工作負載。This detectable performance pattern combines three different cases of plan regression: new plan regression, old plan regression, and existing plans changed workload. 所發生之計畫迴歸的特定類型,會在診斷記錄的 [詳細資料] 屬性中提供。The particular type of plan regression that occurred is provided in the details property in the diagnostics log.

新計畫迴歸情況所指的狀態是 SQL Database 開始執行效率比舊計畫差的新查詢執行計畫。The new plan regression condition refers to a state in which SQL Database starts executing a new query execution plan that isn't as efficient as the old plan. 舊計畫迴歸情況所指的狀態是 SQL Database 從使用較有效率的新計畫切換成使用效率比新計畫差的舊計畫。The old plan regression condition refers to the state when SQL Database switches from using a new, more efficient plan to the old plan, which isn't as efficient as the new plan. 現有計畫變更工作負載迴歸所指的狀態是新計畫和舊計畫會不斷交替,並逐漸朝向效能不佳的計畫方向發展。The existing plans changed workload regression refers to the state in which the old and the new plans continuously alternate, with the balance going more toward the poor-performing plan.

如需有關計畫迴歸的詳細資訊,請參閱什麼是 SQL Server 中的計畫迴歸?(英文)。For more information on plan regressions, see What is plan regression in SQL Server?.

疑難排解Troubleshooting

診斷記錄會輸出查詢雜湊、良好計畫識別碼、不良計畫識別碼,以及查詢識別碼。The diagnostics log outputs the query hashes, good plan ID, bad plan ID, and query IDs. 您可以使用此資訊作為疑難排解的基礎。You can use this information as the basis for troubleshooting.

您可以分析對特定的查詢 (可以藉由系統提供的查詢雜湊來識別) 而言哪個計畫的效能較佳。You can analyze which plan is better performing for your specific queries that you can identify with the query hashes provided. 判斷出哪個計畫較適用於您的查詢之後,您即可手動強制執行該計畫。After you determine which plan works better for your queries, you can manually force it.

如需詳細資訊,請參閱了解 SQL Server 如何防止計畫迴歸 (英文)。For more information, see Learn how SQL Server prevents plan regressions.

提示

您知道 SQL Database 內建的智慧功能可以自動為資料庫管理效能最佳的查詢執行計畫嗎?Did you know that SQL Database built-in intelligence can automatically manage the best-performing query execution plans for your databases?

如需 SQL Database 的持續效能最佳化,建議您啟用 SQL Database 自動調整For continuous performance optimization of SQL Database, we recommend that you enable SQL Database automatic tuning. 這個獨特的 SQL Database 內建智慧功能,能夠持續監視您的 SQL 資料庫,並自動為資料庫調整及建立效能最佳的查詢執行計畫。This unique feature of SQL Database built-in intelligence continuously monitors your SQL database and automatically tunes and creates best-performing query execution plans for your databases.

資料庫範圍設定值變更Database-Scoped Configuration Value Change

發生的情況What is happening

這個可偵測的效能模式表示一種情況,亦即資料庫範圍設定已發生變更,而此情況導致偵測到與過去七天的資料庫工作負載行為相比,效能呈現衰退。This detectable performance pattern indicates a condition in which a change in the database-scoped configuration causes performance regression that is detected compared to the past seven-day database workload behavior. 此模式代表最近對資料庫範圍設定所做的變更似乎對資料庫效能沒有幫助。This pattern denotes that a recent change made to the database-scoped configuration doesn't seem to be beneficial to your database performance.

您可以為每一個個別的資料庫設定資料庫範圍設定變更。Database-scoped configuration changes can be set for each individual database. 這個設定是依個案使用,以將您資料庫的個別效能最佳化。This configuration is used on a case-by-case basis to optimize the individual performance of your database. 以下是可針對每一個個別資料庫設定的選項:MAXDOP、LEGACY_CARDINALITY_ESTIMATION、PARAMETER_SNIFFING、QUERY_OPTIMIZER_HOTFIXES,以及 CLEAR PROCEDURE_CACHE。The following options can be configured for each individual database: MAXDOP, LEGACY_CARDINALITY_ESTIMATION, PARAMETER_SNIFFING, QUERY_OPTIMIZER_HOTFIXES, and CLEAR PROCEDURE_CACHE.

疑難排解Troubleshooting

診斷記錄會輸出最近所進行且與過去七天的工作負載行為相比,導致效能降低的資料庫範圍設定變更。The diagnostics log outputs database-scoped configuration changes that were made recently that caused performance degradation compared to the previous seven-day workload behavior. 您可以還原對先前值的設定變更。You can revert the configuration changes to the previous values. 您也可以逐值調整,直到取得所需的效能層級。You also can tune value by value until the desired performance level is reached. 您可以從具有滿意效能的類似資料庫複製資料庫範圍設定值。You can copy database-scope configuration values from a similar database with satisfactory performance. 如果無法針對效能進行疑難排解,請還原成預設的 SQL Database 預設值,然後嘗試從此基準開始進行微調。If you're unable to troubleshoot the performance, revert to the default SQL Database default values and attempt to fine-tune starting from this baseline.

如有關將資料庫範圍設定最佳化,以及變更設定之 T-SQL 語法的詳細資料,請參閱變更資料庫範圍設定 (Transact-SQL) (機器翻譯)。For more information on optimizing database-scoped configuration and T-SQL syntax on changing the configuration, see Alter database-scoped configuration (Transact-SQL).

用戶端執行速度太慢Slow Client

發生的情況What is happening

這個可偵測的效能模式表示一種情況,亦即使用 SQL 資料庫的用戶端在取用來自資料庫的輸出時,其速度比資料庫傳送結果的速度還要慢。This detectable performance pattern indicates a condition in which the client using the SQL database can't consume the output from the database as fast as the database sends the results. 由於 SQL Database 並不會將所執行查詢的結果暫存在緩衝區中,因此它會減緩速度並等候用戶端取用所傳輸的查詢輸出,然後才繼續進行。Because SQL Database isn't storing results of the executed queries in a buffer, it slows down and waits for the client to consume the transmitted query outputs before proceeding. 這種情況也可能與網路速度不足以將來自 SQL Database 的輸出傳輸給取用的用戶端有關。This condition also might be related to a network that isn't sufficiently fast enough to transmit outputs from the SQL database to the consuming client.

只有當偵測到效能與過去七天的資料庫工作負載行為相比出現降低時,才會產生此情況。This condition is generated only if a performance regression is detected compared to the past seven-day database workload behavior. 只有在統計上與先前的效能行為相比出現明顯降低時才會偵測到此效能問題。This performance issue is detected only if a statistically significant performance degradation occurs compared to previous performance behavior.

疑難排解Troubleshooting

這個可偵測的效能模式表示一種用戶端的情況。This detectable performance pattern indicates a client-side condition. 需針對用戶端應用程式或用戶端網路進行疑難排解。Troubleshooting is required at the client-side application or client-side network. 診斷記錄會輸出查詢雜湊,以及過去兩小時內等候用戶端取用它們等得最久的等候時間。The diagnostics log outputs the query hashes and wait times that seem to be waiting the most for the client to consume them within the past two hours. 您可以使用此資訊作為疑難排解的基礎。You can use this information as the basis for troubleshooting.

您可以將應用程式取用這些查詢的效能最佳化。You can optimize performance of your application for consumption of these queries. 您也可以考慮可能的網路延遲問題。You also can consider possible network latency issues. 因為效能降低問題是以過去七天的效能基準為基礎,您可以調查此效能降低事件是否是由最近的應用程式或網路狀況變更所造成。Because the performance degradation issue was based on change in the last seven-day performance baseline, you can investigate whether recent application or network condition changes caused this performance regression event.

定價層降級Pricing Tier Downgrade

發生的情況What is happening

這個可偵測的效能模式表示一種情況,亦即您 SQL Database 訂用帳戶的定價層已被降級。This detectable performance pattern indicates a condition in which the pricing tier of your SQL Database subscription was downgraded. 由於資料庫可用的資源 (DTU) 減少,因此系統偵測到目前的資料庫與過去七天的基準相比出現效能降低。Because of reduction of resources (DTUs) available to the database, the system detected a drop in the current database performance compared to the past seven-day baseline.

此外,也可能是發生 SQL Database 訂用帳戶的定價層降級,然後在短期間內又升級到較高層級的情況。In addition, there could be a condition in which the pricing tier of your SQL Database subscription was downgraded and then upgraded to a higher tier within a short period of time. 對此暫時性效能降低的偵測,會在診斷記錄的 [詳細資料] 區段中會輸出成定價層降級和升級。Detection of this temporary performance degradation is outputted in the details section of the diagnostics log as a pricing tier downgrade and upgrade.

疑難排解Troubleshooting

如果您已降低定價層 (因而減少 SQL Database 可用的 DTU),並對效能感到滿意,便無須採取任何動作。If you reduced your pricing tier, and therefore the DTUs available to SQL Database, and you're satisfied with the performance, there's nothing you need to do. 如果在降低定價層之後,您對 SQL Database 的效能感到不滿意,請降低資料庫工作負載,或考慮將定價層提升到較高的層級。If you reduced your pricing tier and you're unsatisfied with your SQL database performance, reduce your database workloads or consider increasing the pricing tier to a higher level.

請依照下方流程圖所提供的建議方法,使用 Intelligent Insights 來針對效能問題進行疑難排解。Follow the flowchart for a recommended approach to troubleshoot performance issues by using Intelligent Insights.

透過 Azure 入口網站瀏覽至 [Azure SQL 分析] 來存取 Intelligent Insights。Access Intelligent Insights through the Azure portal by going to Azure SQL Analytics. 嘗試找出傳入的效能警示,然後選取該警示。Attempt to locate the incoming performance alert, and select it. 在 [偵測] 頁面上識別發生的情況。Identify what is happening on the detections page. 觀察所提供的問題根本原因分析、查詢文字、查詢時間趨勢,以及事件演進情況。Observe the provided root cause analysis of the issue, query text, query time trends, and incident evolution. 使用 Intelligent Insights 針對緩和效能問題所提出的建議來嘗試解決該問題。Attempt to resolve the issue by using the Intelligent Insights recommendation for mitigating the performance issue.

疑難排解流程圖Troubleshooting flow chart

提示

選取流程圖以下載 PDF 版本。Select the flowchart to download a PDF version.

Intelligent Insights 通常需要一小時的時間來執行效能問題的根本原因分析。Intelligent Insights usually needs one hour of time to perform the root cause analysis of the performance issue. 如果無法在 Intelligent Insights 中找到您的問題,且此問題對您而言很嚴重,請使用查詢存放區以手動識別效能問題的根本原因。If you can't locate your issue in Intelligent Insights and it's critical to you, use the Query Store to manually identify the root cause of the performance issue. (這些問題存在的時間通常不會超過一個小時)。如需詳細資訊,請參閱使用查詢存放區監視效能(Typically, these issues are less than one hour old.) For more information, see Monitor performance by using the Query Store.

後續步驟Next steps