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! Join Processing Rows must be on the same AMP to be joined. If necessary, the system creates spool copies of one or both rows and moves them to a common AMP. Join processing NEVER moves or changes the original table rows. Typical kinds of joins are: Merge Join Product Join Nested Join Exclusion Join The Optimizer chooses the best join strategy based on: Available Indexes Demographics (COLLECTed STATISTICS or Dynamic Sample) EXPLAIN shows what kind of join a query uses. 在SQL中尽最大可能避免Product Join。 一般优化策略 尽量利用分区 尽量创造条件使用分区，例如截取输入机构代码的前两位和省份代码相比（注: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 ; 处理策略 在Spool空间建立一个临时日期表（一个季度包含90条记录）； 复制临时日期表 将日期表和历史表进行Product join(即历史表每条记录进行90次比较) 或，对日期表和历史表进行排序后进行Merge join 解决思路－泛化处理 一种解决思路，对历史表进行泛化处理Denomalize 在历史表中增加日期所属季节字段 处理时候，直接根据增加的字段进行汇总 后果 泛化处理增加了表的维护工作，处理脚本需要进行该字段的计算 冗余的字段增加了I/O负担 所以这种处理方案并不理想。 推荐方案－利用Between进行日期比较 目的：产生某一阶段的汇总。如根据历史表，对一个季度的不同储种账户数量汇总。 SQL： SELECT H.product_id , SUM(H.account_num) FROM History H , (SELECT min(calendar_dat