8

在 Teradata 中，我可以使用类似 ...

collect statistics on my_table column(col1)

这将收集表上的统计信息并将它们存储在 DBC 视图中，如 ColumnStats、IndexStats 和 MultiColumnStats。我还认为优化器（解析引擎）会在可用时找到统计信息并使用它们而不是估计的表基数/索引值计数来更好地决定如何执行查询。

这一切听起来都很棒，但我有一些问题。

  • 使用有什么缺点collect stats吗？
  • 什么时候适合/不适合在 SQL 脚本中使用收集统计信息？
  • 收集已编入索引的字段的统计信息有什么性能优势？
  • （表、易失性表）的统计信息存储多长时间？
  • 任何其他有关的评论collect statistics将不胜感激。
4

1 回答 1

15

1>使用收集统计数据有什么缺点吗？

是的，收集统计数据本身很耗时，它实际上是从 AMPS 中定位数据并将统计数据插入字典表中。

假设您有一个表定义，例如：

ct t1(x1 int,y1 int, z1 int);

该表包含数百万行，并且 z1 从未在 ST/Join 条件中使用，因此不值得收集 z1 上的统计信息。

2>什么时候在你的 SQL 脚本中使用收集统计信息是合适的/不合适的？

上面已经回答了。如果一列将用作 ST/Join 条件。即在 where 或 on 子句中，您必须收集统计信息，否则不需要。

3> 收集已编入索引的字段的统计信息有什么性能优势？

ct t1(x1 int,y1 int) 主索引(x1);

对于像 sel * 这样的简单查询 from t1 where x1 = 5;

将展示收集统计数据的有用性。

如何？

优化器可以正确估计该查询将选择多少行，如果 t1 将与 t2 连接，优化器将选择一个有效的连接。

4>（表、易失性表）的统计信息存储多长时间？

表：永久。

易失性表：直到会话到期。

5>任何其他关于收集统计的意见将不胜感激。

没有任何关于多列统计的讨论。

说，查询是这样的：

sel * from t1 join t2 on y1=y2 and x1=2;

那么在 (x1,y1) 上收集多列统计信息将非常有助于优化。

此外，如果表人口统计已更改（行数增加），您必须考虑重新收集统计信息

于 2013-05-28T19:28:54.500 回答