可以与任意表关联，无需对应分区，无需相同分区数。
实际上数据量不大的表优先考虑建成维度表，特别是需要与其他表要关联的表。
维度表的劣势：查询性能不随着扩容提升，浪费更多存储空间，但是对于数据量不大的情况下都不是问题。
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，但是效率较低，最重要的是我现在私有云没有新引擎：)
持续更新中...
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有