收集统计信息以最大限度的利用你的系统

 对Teradata查询优化器优化性能来说统计信息的收集是必要的，查询优化器依赖统计信息的帮助选择最优的访问数据的方法。统计信息可以帮助优化器确定被查询的表中有多少行数据和多少行数据满足过滤条件。如果缺少这些统计信息，或者过期的统计信息都会导致优化器选择一个并不理想的访问数据的方法。
   这篇文章主要回答下面问题：什么样的统计信息值得收集？多久我们收集一次，如何收集？是否存在一种情况不收集统计信息才是最好的？
什么样的信息值得收集？

   非唯一次索引（NUSI）
   为所有NUSIs 收集统计信息是很重要的，因为统计信息可能会影响优化器是否使用一个次索引，它会在一个查询中产生很大的差异。如果在一个NUSI的定义中有ORDER BY选项，定义了排序键，那收集这个排序键列的统计信息是很重要的，它能使优化器更精确的比较使用和不使用这个次索引所付出的代价。

   唯一主索引（UPI）
   如果一个表很小（每个AMP少于100行数据），并且此表上没有收集统计信息，那么在这个表的PI上收集统计信息是很重要的。优化器只有通过PI上的统计信息才能知道这个表到底有多少行记录。并且，如果我们收集了PI上的统计信息，在多表关联的查询中，优化器能选择更优的执行计划。
  
   非唯一索引（NUPI）
   如果NUPI是高唯一，重复率很低，或者PI经常在连接中使用，那么统计信息是应该收集的。
  
   连接索引（Join Index）
   基础表列和连接索引列的统计信息要分别收集，对基础表和连接索引来说统计信息是不能互相替换的，而且基础表的数据特征和连接索引中的数据的特征是不同的。连接索引的统计信息一般收集连接索引的PI列的。如果它上面有次索引，那么收集次索引列的信息也是很有用的。
  
   连接列（Join Columns ）
   收集那些用来连接表的列的统计信息是相当重要的，尤其是那些用来连接超过2个表的列。对于小表，对所有用于连接的列都收集统计信息是明智的，这将有助于优化器选择最好的表的连接顺序和连接方法。另外，统计信息帮助Teradata决定需要多大的spool空间来存放查询结果。精确的统计信息可以使一个查询成功的运行而不是因为spool空间不够而失败。
   过滤列（Qualifying Columns ）
   任何用在查询where条件中的列也要收集统计信息，特别，那些数据很偏的过滤列的信息收集是必要的，否则优化器会保守的按照一定的比例去估计将被过滤出的记录数，例如，某标志列有Y和N两个值，大部分值是N，那么对这列收集统计信息是明智的。

   总之，如果不确定是否要收集某列的统计信息，那么建议去收集。收集比优化器需要的多的统计数据很少会引起什么问题。大多情况下，只是需要时间和系统资源。但是，缺少统计信息会导致优化结果不理想，影响查询性能，多收集总是比少收集好。

收集统计信息的最佳时间

 在我们确定了哪些列和索引需要收集统计信息后，下一个我们要关注的问题是多久我们收集一次统计信息。收集统计信息的频率依赖一下几个因素：
表的大小，系统的负载量和表里数据的更新频率。

 经常收集小表的统计信息不是问题，因为它们所占用的时间和系统资源是很少的，可以忽略不计的，因此，你可以在每次有数据更新的情况下收集小表的统计信息。
 然而，越大的表需要越多的时间和系统资源，所以中等或者更大的表，你只需要在有一定比例的记录被插入，更新或删除时才需要收集统计信息，建议有10%的记录发生变化时重新收集统计信息。通常，表越大，重新收集的频率越小，当然，对那些频繁被更新的和数据变化很快的大表例外。

收集时机

典型的，通过分析数据表的数据特征和用户的查询模式，数据分析师决定收集某个表的那些统计信息，这步工作完成后，ETL开发人员或者DBA来完成收集统计信息的任务，一般都在数据加载处理完成后，下面情况下都应该收集统计数据：
Fastloads
加载完成或者次索引创建完成时收集统计信息。
Multiloads
小表每次加载完后收集，中表或大表当有一定比例的数据变化后收集，如果索引被drop并在multiload后重新创建，对这些索引收集统计信息。
Non-utility updates (TPump/BTEQ/ODBC/JDBC)
当有一定比例的数据变化后收集统计信息。
Deletes/Purges
当有一定比例的数据被删除后收集统计信息。
Recovery
如果一张表丢失，从存档重新恢复后需要重新收集统计信息。
Reconfiguration
系统重新配置后需要重新收集统计信息

当一个表正在更新时不能收集统计信息。
总之，优化器有更多的统计信息可用，这些统计信息越准确，越新，优化器选取的访问数据的方法越合理，高效。