1 使用explain
Explain 后接查询语句，可以辅助理解SQL运行顺序
例如关联语句 执行顺序select * from one left two on one.列名 = two. 列名 where 过滤条件
顺序1：
对主表限制条件select *from one left two on one.列名 = two. 列名 where one.列名=1。语句会先对one表的where条件过滤数据然后再join two 表
顺序2：
对关联表限制条件select *from one left two on one.列名 = two. 列名 where two.列名=1。语句会在two表据关联之后，在reduce 阶段才会对two表进行过滤。这时候应该将条件写在on后面（select * from one left two on one.列名 = two. 列名 and two.列名=1.ps：left join并不会影响主表，所以这个办法最好在后边的where再加一次条件select * from one left two on one.列名 = two. 列名 and two.列名=1 where two.列名=1。）或者单独写个子查询嵌套进去，这样才能实现先过滤two表数据再进行join 操作；
2 使用show functions
展示可以使用的函数，查看函数使用方法
show functions like '*time*' –展示包含time的函数desc function timestamp --描述函数使用方法
3 窗口函数
辅助数据分析，多维度查询数据
4 reduce过程的百分比与对应的处理如下
0~33%是shuffle的过程，数据从mapper已到了reducer
33~67%是sort的过程，这个过程只会在mapper完成后才会执行
67~100%才是reducer程序执行的过程。如果reduce卡在了67%，那么说明reducer一个也没有执行。可能是输入数据太大，超过了限制，也可能是reducer有死循环的bug
5 数据倾斜问题
1、增加jvm内存,这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)),这种情况下,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。
2、增加reduce的个数,这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一),我们知道,这种情况下,最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。
3、自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。
4、重新设计key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。
5.平台优化方法
使用map join (解决小文件关联问题，小表复制到内存及每个map任务的本地)先group by 在用count设置map端输出中间表结果压缩（减少磁盘I/O）
