對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
系統重新配置後需要重新收集統計資訊

當一個表正在更新時不能收集統計資訊。
總之，優化器有更多的統計資訊可用，這些統計資訊越準確，越新，優化器選取的訪問資料的方法越合理，高效。