0

我目前正在尝试优化我们的后端是 Teradata 的一些 bobj 报告。Teradata 优化器似乎非常挑剔，我想知道是否有人提出了解决方案或解决方法来让优化器以与 equals 类似的方式对待 likes。

My issue is that we allow the user to input one of two methods:
 1. Enter the Number:
    or
 2. Enter a Number like:

选项一表现得像梦一样，而选项二将我们的查询时间从 6 秒拖到 2 分钟。

除此之外; 有没有人知道任何关于优化 teradata 优化器的 SQL 语句的好文章、讨论、视频等？

4

4 回答 4

1

我认为 Number 已编入索引？Teradata 使用散列进行索引，因此 equals 将导致使用索引，而 like 将导致全表扫描。

如果您真的需要使用 like，那么您可以做的事情并不多。您可以尝试的一件事是使用Substr(Number, 1, 3) = '123'而不是Number LIKE '123%'. 过去我已经从中获得了小的性能改进，但不要指望有什么壮观的。

于 2010-09-15T09:11:05.470 回答
1

您将需要全文索引/预标记索引，例如 lucene，以及两次解析搜索。

例如，当在数据库中插入“12345”时，创建从“1”、“12”、“123”、“234”...等到“12345”的链接。

然后，当使用 find 类似“123**”时，从查找表中找到“123”并查找记录“12345”

于 2010-09-15T09:18:39.643 回答
1

如果您正在进行直接的 VARCHAR 比较，即

Column LIKE 'VALUE'

那么您可以尝试在该列上使用 NUSI。确保为表的主索引和索引收集统计信息

于 2010-09-15T19:06:21.733 回答
1

因为该列被定义为 VARCHAR 并且您使用的是 LIKE 运算符，所以您消除了使用 PI 进行单个 AMP 访问的可能性。请记住，主索引的首要任务是在系统中的 AMP 之间分发数据。因为您对 PI 使用 LIKE 运算符，所以优化器必须执行“所有 AMP”操作以满足 LIKE 运算符。

WHERE MyPIColumn LIKE '123%'

以 123 开头的值的散列可以并且最终会出现在多个 AMP 上。

WHERE MyPIColum = '123'

123 的散列会将每条记录放在同一个 AMP 上。查询“123”将始终是单个 AMP 操作。

这方面的统计数据可能有助于行估计，但可能不会消除“所有 AMP”操作。

  1. 这是唯一 PI 还是非唯一 PI？
  2. 为什么选择的数据类型是字符而不是数字？尽管 GT(E) 或 LT(E) 可能会导致相同的“全 AMP”操作。
  3. 此 PI 是否由模型中的其他表共享以促进 AMP 本地连接策略？
于 2010-09-30T16:20:53.893 回答