本文說明開發 Azure 串流分析查詢時的常見問題、如何對查詢問題進行疑難排解，以及如何修正問題。 許多故障排除步驟都需要你啟用 Stream Analytics 工作的資源日誌。 如果你沒有啟用資源日誌，請參考「使用資源日誌排除 Azure 串流分析 故障」一節。
查詢沒有產生預期的輸出
在本機執行測試以檢查錯誤：
在適用於 Visual Studio Code 的 Azure 串流分析工具中，使用作業圖表在本機逐步對查詢進行偵錯。 工作圖展示了資料如何從輸入來源（例如 Azure 事件中樞 和 Azure IoT 中樞）經過多個查詢步驟，最後流向輸出匯。 腳本會將每個查詢步驟映射到你用 WITH 陳述式定義的臨時結果集。 查看每個中間結果集的資料與指標，以找出問題來源。
如果您使用 Timestamp By，請確定事件有大於作業開始時間的時間戳記。
排除常見的錯誤，例如︰
確保你依預期配置事件排序政策。 移至 [設定]，然後選取 [事件排序]。 Test 按鈕在您測試查詢時不會套用該原則。 這個結果是瀏覽器內測試與在生產環境中執行作業之間的一個差異。
使用活動和資源記錄檔進行偵錯：
以漸進方式對查詢偵錯
在即時資料處理中，知道查詢中資料的樣貌會很有幫助。 要查看中間資料，請使用Visual Studio中的工作圖。 如果你沒有 Visual Studio，可以採取額外步驟來輸出中間資料。
因為 Azure 串流分析 可以多次讀取工作中的輸入或步驟，你可以寫額外的SELECT INTO語句。 這樣做會將中間資料寫入儲存體，並讓你檢查資料的正確性，就如同你在除錯程式時使用 監看變數 一樣。
下列 Azure 串流分析作業中的查詢範例包含一個串流輸入、兩個參考資料輸入，以及一個輸出至 Azure 資料表儲存體的輸出。 查詢會串聯來自事件中樞和兩個參考 Blob 的資料，以取得名稱和類別資訊：
作業正在執行，但輸出中未產生任何事件。 在這裡顯示的 監控 圖塊上，你可以看到輸入正在產生資料，但你不知道 JOIN 的哪一步把所有事件都丟棄了。
在這種情況下，你可以加幾個額外的 SELECT INTO 語句來「記錄」 JOIN 中間結果和從輸入讀取的資料。
在此範例中，我們新增了兩個新的「暫時輸出」。它們可以是您喜歡的任何接收器。 在這裡我們使用 Azure 儲存體作為範例︰
然後您可以重新撰寫查詢，如下所示︰
現在請再次啟動作業，並讓它執行幾分鐘的時間。 接著查詢temp1並temp2使用 Visual Studio Cloud Explorer 產生以下表格：
temp1 資料表
temp2 表格
如您所見，temp1 和 temp2 都有資料，而且在 temp2 中，name 欄已正確填入資料。 然而，由於輸出仍無資料，顯示出了問題：
透過抽樣資料，你幾乎可以確定問題出在第二個 JOIN。 您可以從 Blob 下載參考資料並查看：
如您所見，此參考資料中的 GUID 格式與 [from] 中的 temp2 欄位格式不同。 這就是為什麼資料沒有如預期送達 output1 。
修正資料格式，上傳到參考 blob，然後再試一次：
此時，輸出中的資料已如預期般進行格式化並填入。
資源使用率偏高
請確實利用 Azure 串流分析中的平行處理。 了解如何透過設定輸入分割區及微調分析查詢定義，以查詢平行化擴展串流分析作業。
如果資源使用率持續超過 80%，浮水印延遲就會增加，且待處理事件的數目也會增加，請考慮增加串流單位。 高使用率表示作業使用接近配置資源的上限。
獲得協助
如需進一步的協助，請嘗試 Azure 串流分析的 Microsoft 問與答頁面。