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找到后，将他们分开处理；
更多请参考社区文档与官方文档！