簡介
當你 錄 下想用的診斷後，下一步就是要能夠理解它們說的內容。
了解查詢診斷架構中每一欄的具體意義會很有幫助，這部分我們在這個簡短的教學中不會重複。 這裡有完整的說明。
一般來說，建立視覺化時，最好使用完整的詳細表格。 因為不管有多少列，你看到的很可能是某種不同資源時間累積的描述，或是原生查詢的總值。
如我們在記錄診斷的文章中提到，我正在處理同一個（或接近相同的）Northwind資料庫中的 Customers 表，使用 OData 和 SQL 的追蹤資料。 特別是，我會聚焦於客戶常見的請求，以及其中一組較容易解讀的痕跡：資料模型的全面刷新。
建構視覺化圖表
當你在檢視痕跡時，有很多方法可以評估它們。 本文將聚焦於兩種視覺化的分割——一種是顯示你關心的細節，另一種則是輕鬆檢視各種因素的時間貢獻。 第一個視覺化會使用一張表格。 你可以選擇任何你喜歡的領域，但建議用來簡單且大致了解狀況的領域有：
第二個視覺化的選項是使用堆疊欄狀圖。 在「Axis」參數中，你可能想使用「Id」或「Step」。 如果我們要看刷新，因為它和編輯器本身的步驟無關，我們大概只想看「Id」。 對於「Legend」參數，你應該設定「Category」或「Operation」（視你想要的細度而定）。 對於「Value」，設定「Exclusive Duration」（並確保不是 %，這樣才能得到原始的持續時間值）。 最後，在提示中設定「最早 開始時間」。
視覺化完成後，記得依「最早 開始時間」由高到低排序，這樣你才能看到事情發生的順序。
雖然您的具體需求可能不同，但這組圖表組合是檢視多種診斷檔案及多種用途的良好起點。
解讀視覺化
如前所述，你可以嘗試用查詢診斷來回答許多問題，但我們最常看到的兩個問題是：時間花了多少，以及查詢送給來源的是什麼。
詢問時間的使用方式是很簡單的，對於大多數連接器來說都是相似的。 查詢診斷的一個警告，如其他地方提到的，你會看到不同連接器的功能差異很大。 舉例來說，許多基於 ODBC 的連接器無法準確記錄送往實際後端系統的查詢內容，因為 Power Query 只看到它傳送給 ODBC 驅動程式的內容。
如果我們想知道時間如何被使用，只要看上面我們建立的視覺化即可。
現在，因為我們這裡使用的範例查詢的時間值非常小，如果我們想處理 Power BI 如何回報時間，最好在 Power Query 編輯器中將 專屬持續時間 欄位轉換成「秒數」。 完成這個換算後，我們就能查看圖表，並大致了解時間花在哪裡。
以我的 OData 結果為例，我在圖片中看到大部分時間都花在從來源取得資料——如果我選擇圖例上的「資料來源」項目，它會顯示所有與向資料來源發送查詢相關的各種操作。
如果我們執行所有相同的操作並建立類似的視覺化，但用 SQL 追蹤而非 ODATA 的，就能看到兩個資料來源的比較！
如果我們選擇資料來源資料表，就像 ODATA 診斷一樣，我們可以看到第一次評估（這張圖中的 2.3）會發出元資料查詢，第二次評估則實際取得我們關心的資料。 因為這次我們取得的資料量很小，拉回的資料需要很短的時間（整個第二次評估不到十分之一秒，資料檢索本身不到二十分之一秒），但並非所有情況都如此。
如上所述，我們可以在圖例中選擇「資料來源」類別，以查看已發出的查詢。
深入分析資料
觀察路徑
當你查看此內容時，如果時間花費看起來很奇怪，例如在 OData 查詢內，你可能會看到有一個資料來源查詢，值如下：
Request:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle%20eq%20%27Sales%20Representative%27&$select=CustomerID%2CCountry HTTP/1.1
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
<Content placeholder>
Response:
Content-Type: application/json;odata.metadata=minimal;q=1.0,application/json;odata=minimalmetadata;q=0.9,application/atomsvc+xml;q=0.8,application/atom+xml;q=0.8,application/xml;q=0.7,text/plain;q=0.7
Content-Length: 435
<Content placeholder>
此資料來源查詢與一個操作相關聯，該操作僅佔獨佔期間的比例，例如 1%。 同時，也有類似的例子：
Request:
GET https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry HTTP/1.1
Response:
https://services.odata.org/V4/Northwind/Northwind.svc/Customers?$filter=ContactTitle eq 'Sales Representative'&$select=CustomerID%2CCountry
HTTP/1.1 200 OK
此資料來源查詢與一項佔據排他期間近 75% 的操作相關聯。 如果你開啟 這條道路，你會發現後者其實是前者的子嗣。 這表示第一個查詢本身就增加了一點時間，實際的資料檢索則由「內部」查詢追蹤。
這些都是極端的數值，但在可能被看到的範圍內。