1.分段調試
面對長的SQL，出錯時一般直接看定位的行號，有時候不出錯但是沒數據時，應該嘗試分段調試，很長的SQL嵌套很多的子查詢時，一個一個子查詢進行分別調試，看哪一步子查詢出了問題，層層推進
2.日志查看
通常情況下，日志都是很重要的指示。有時候一些莫名其妙的錯誤時，錯誤信息看得懂卻始終調不通時，不妨嘗試查看運行的日志（例如相關的設置項，系統解析出來運行的SQL等）
logview：ODPS的Debug工具
一般在運行節點時日志會打印出Logview：
當然，Logview其實是有規律的，通過參數分析也能得到instanceID等信息。如果有時候出現如下權限的現象：
使用命令wait instanceID即可！
Logview頁面參數簡介：
其他顯而易見的就不贅述了，task字段比較容易理解，不再贅述：
Diagnosis就是診斷信息（包括資源診斷，長尾診斷）
我們重點關注的就是detail，task類型講解參見本文第4點。
任意展開一個Instance：
需要關注的參數的介紹：
還有需要注意的是Logview系統只保留7天，7天之后還想分析需要先保存，再上傳進行查看：
logview診斷方法：
（1）錯誤：這個通過控制台的日志或者Logview的result錯誤代碼和錯誤提示，相對排查比較直觀
（2）慢任務排隊：這個可以通過logview的status查看排隊狀態，通過show p 查看所有Instance，通過top instance查看當前正在執行的作業信息
3.樣本數據比對
有時候比如一些表連接操作等一直連接不上，語法日志方面又沒問題但就是沒數據，那不如取出幾條樣本數據來比對，看到真實數據有時候可以比較直觀的看到問題所在
常見MaxComputer錯誤：
https://yq.aliyun.com/articles/616705
4.長尾問題調優
官方文檔參考：https://help.aliyun.com/document_detail/51020.html?spm=5176.10695662.1996646101.searchclickresult.65ac2d43zPlfxk
https://help.aliyun.com/video_detail/91702.html?spm=5176.11065259.1996646101.searchclickresult.300e2edfH6w6qH
1.切入點：logview
通過details可以定位長尾的位置：
// task類型：
- 在每個Task中，可以看到Task的名字，對於M1，表示這是一個Map task，R5_4中的4表示它依賴J4執行結束才能開始執行。同理，J4_1_2_3表示Join4這個階段要依賴M1、M2、M3三個task完全成才能啟動運行。
2.常見解決方案
·經典word_count的長尾：
SELECT a.key , COUNT(*) AS cnt FROM a GROUP BY a.key
使用groupby參數，進行熱點Key的打散：
set odps.sql.groupby.skewindata=true
此方法僅對長尾問題比較嚴重的有效！（分鍾級內慎用！）
DISTINCT長尾：
DISTINCT不會再shuffer進行一次聚合操作，會全部傳入給reduce進行處理！相對沒有group by效率高！
采用去重統計的辦法：
--原始SQL,不考慮Uid為空
SELECT COUNT(uid) AS Pv , COUNT(DISTINCT uid) AS Uv FROM UserLog;
一個方式是改寫，把DISTINCT改成普通的COUNT：
SELECT SUM(PV) AS Pv , COUNT(*) AS UV FROM ( SELECT COUNT(*) AS Pv , uid FROM UserLog GROUP BY uid ) a;
如果發現是特殊值引起的長尾（例如NULL特別多），則可以考慮先過濾再處理
動態分區長尾：
通過關閉reshuffer參數（默認開啟的），來取消減少rudece的個數
JOIN長尾：
首先考慮能不能用mapjoin；
第二考慮分而治之，因為長尾原因就是熱點KEY太多，把熱點KEY通過GROUP BY 、ORDER BY找到后，將他們分開處理；
更多請參考社區文檔與官方文檔！