1.ads中非分区表关联问题
无法关联或关联出结果不对，主要因为ads目前的非分区表之间的关联仅支持分区列，且分区数相同，主因为ads关联首先根据分区对应，所以所关联的表与当前表分区字段必须一致，分区数也必须一致，否则得到的结果会跟你想象中差很多。而与分区表关联则不受此限制。
使用ads中的维度表
可以与任意表关联，无需对应分区，无需相同分区数。
实际上数据量不大的表优先考虑建成维度表，特别是需要与其他表要关联的表。
维度表的劣势：查询性能不随着扩容提升，浪费更多存储空间，但是对于数据量不大的情况下都不是问题。
2.ads不支持带偏移量的limit
实际上无法做成真实分页，而且最多只能取出前1w条数据。可以使用dump方式解决，但是不建议那么做，ads主要关注快速获得查询结果，并不适用此场景。
3.ads支持count(distinct columnName)
需修改后台配置，
/global/config/query –>新增enableUdfSysGroupDistinctConcat bool类型，值false，然后count distinct可以即时生效
4.UNION无法使用或结果错误
目前仅支持分区列UNION，所以带group by的聚合函数结果或查询出的非分区列结果都不可以使用union。
注：以上基于0.8.18版本，后续版本有所更新，会另写文详解。
之后更新会说明版本。
=====20160805更新===========
版本0.9.10
ads性能优化
1.注意过滤条件加上表别名
2.打平关联语句（采用直接关联表而非关联子查询的方式）
3.将关联条件设置为表聚集列
为什么打平（直接关联表而不采用关联子查询的方式）会比子查询快，这里面涉及什么原理？
打平之后，关联的维度表成为右表，join的时候走索引，所以很快；而子查询情况下，维度表就只能作为左表（子查询会自动将其处理为左表），实时表成为右表。实时部分的数据因为没有强大的索引，所以只能走扫描，这样就慢了。
遇到一个坑！！！强调下！！！
select … a join b where xrsj>….
（a为大表，上百亿数据，b为维度表，上万数据）
这种语句执行的时候，当xrsj这个字段只有a或者b表的时候是完全没问题的，碰巧就是a、b表都有xrsj这个字段的时候，按常理来说，应该报错的！怎么都应该报错才对，然后秀逗了，居然没有报错，还欢快地跑起来了，以至于我一个月都没找到为什么语句那么慢！
所以优化第一句就是过滤条件要加上表别名。
这个bug已经提交给ads开发经理了，不过回复我优先级不会很高，什么时候修复再说。
=====201608011更新===========
分区表与Group-By、Order-By查询
Group-By条件包含分区列，则应该放到第一列，此时结果是精确的且查询性能很好
Group-By表达式如果不包含分区列（或第一列不是分区列），则分组数量在范围内（<5000），结果是精确的，但性能随分组数量增加而降低
Group-By表达式如果不包含分区列（或第一列不是分区列），且分组数量不在范围内（>=5000），此时结果是不精确的且性能随分组数量增加而降低
如果Group-By表达式第一列不是按分区列，则Having语句不支持
全局分组TOP(N)：Group-By表达式包含分区列，则应该放到第一列，同时包含Order-By表达式，如果分组数量在范围内（<1000），结果是精确的，但性能随分组数量增加而较大降低
全局模糊分组TOP(N)：Group-By表达式第一列如果不是分区列且包含Order-By表达式，而且分组
数量不在范围内（>=1000），此时结果是不精确的且性能随分组数量增加而较大降低
全数据排序：Order-By表达式第一列如果不是分区列，性能会随排序列或表达式取值增加而较大降
使用新引擎不受限制，我估计以后的问题，新引擎都不受限制，毕竟就是为了最大化兼容sql，但是效率较低，最重要的是我现在私有云没有新引擎：)
持续更新中…