Teradata优化.ppt

Teradata SQL 技巧  优化前提 保证数据正确性与一致性 对于后台脚本，优化时还要考虑作业间关系，不能为了优化破坏脚本的逻辑及依赖关系 所有的优化不能脱离DDL及数据库本身的机制 优化内容 DDL 表级优化 PI/PPI 字段长度 字段压缩 SI/USI SQL 写法 表关联、导出表、临时表 避免重复扫描同一张表 避免隐式转换 数据分布策略 PI PPI（数据分布不均匀是大忌） 在Teradata中,PI的选择十分重要,选取不正确，则有如下的影响： 影响数据分布，不好评估数据库空间使用情况； 影响性能。 选择PI的大致原则:ACCESS(访问)+DISTRIBUTION(分布)+VOLATILITY(可变性) 即选择那些经常需要引用或用作关联的、能让表数据均匀分布、相对比较稳定(经常变化必然导致数据在AMP间的迁移)的字段做PI. 表一定要有PI,如果你没有指定,Teradata会按如下原则指定PI: 1)有PK的话,用PK字段作为UPI. 2)没有PK的话,有USI的话,将USI的字段做UPI. 3)没有PK,没有USI的话,将第一个字段作为NUPI. 所以,尽量自己去指定PI! 一般优化策略 尽量利用分区 尽量创造条件使用分区，例如截取输入机构代码的前两位和省份代码相比（注:Teradata中的PARTITION概念不同于ORACLE中的PARTITION概念,前者是逻辑上,后者是物理上的,所以在使用上还是很大的区别） 在有关联的情况下因该采用这种写法A.Province_Cd=B.Province_Cd And A.Province=xx 表与表的关联，尽量通过两个表的PI字段进行关联，避免数据的重分布 若PI由多个字段组成，则要将多个字段列全，否则PI会不使用 关联条件不可忽略，避免迪卡尔乘积 在SQL中列全所需要的所有字段，避免select * from TableName，减少SPOOL空间开销; 尽量减少数据重分布 目的：产生某一阶段的汇总。如根据历史表，对一个季度的不同储种账户数量汇总。 SQL： SELECT H.product_id , count(H.account_num) FROM History H , Calendar C WHERE C.quarter = 3 AND C.calendar_date = H.sale_date GROUP BY 1 ORDER BY 1 ; 解决思路－泛化处理 一种解决思路，对历史表进行泛化处理Denomalize 在历史表中增加日期所属季节字段 处理时候，直接根据增加的字段进行汇总 后果 泛化处理增加了表的维护工作，处理脚本需要进行该字段的计算 冗余的字段增加了I/O负担 所以这种处理方案并不理想。 推荐方案－利用Between进行日期比较 目的：产生某一阶段的汇总。如根据历史表，对一个季度的不同储种账户数量汇总。 SQL： SELECT H.product_id , SUM(H.account_num) FROM History H , (SELECT min(calendar_date) , max(calendar_date) FROM Calendar WHERE quarter = 3) AS DT (min_date, max_date) WHERE H.sale_date BETWEEN DT.min_date and DT.max_date GROUP BY 1 ORDER BY 1; 派生表的关联和累计 派生表是在子查询中产生的临时表，用户无须主动Create/Drop操作。在合适的场景中恰当的使用派生表能够起到很好的优化作用 目的：生成某个储种的余额信息，而储种的描述存放在储种表中，所以需要把事实表和代码表进行关联生成报表信息。下面的例子是普通的Join示例，无派生表： SQL SELECT A.product, B.description, SUM(A.bal) FROM History A, Code B WHERE A.product = B.product GROUP BY 1, 2 ; 派生表的关联和累计-解决方法 优化方法：使用派生表，先进行汇总，然后汇总的结果进行关联，虽然只是操作顺序上的改变，但是在最耗时的关联操作时，只是两张小表之间的操作，因此运行效率远高于前者,这种做法在加工汇总表的时候尤其需