SQL 中的 Teradata Optimizer Equal vs Like答案

【问题标题】：Teradata Optimizer Equal vs Like in SQLSQL 中的 Teradata Optimizer Equal vs Like
【发布时间】：2011-04-12 08:21:51
【问题描述】：

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

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 语句的好文章、讨论、视频等？

【问题讨论】：

【解决方案1】：

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

WHERE MyPIColumn LIKE '123%'

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

WHERE MyPIColum = '123'

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

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

【讨论】：

Rob 谢谢你的回复。数字只是一个例子。我们被要求用户必须能够对我们查询集中的任何内容进行通配符。这不是最优的，因为在许多情况下我们有 4-5 个表（有时是 L/R 外连接），每个表有 4-7 百万行。
您可能希望考虑不用于访问数据的代理键。这将允许您在用于选择标准的值上构建 NUSI，希望优化器至少在某些时候会考虑使用 NUSI 访问数据。它应该取决于统计中列的数据人口统计。我建议合并一个控制表，其中存储了每个表的最后一个代理值，以避免扫描较大的表以查找代理的种子值。

【解决方案2】：

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

如果您确实需要使用 like，那么您无能为力。您可以尝试的一件事是使用Substr(Number, 1, 3) = '123' 而不是Number LIKE '123%'。过去，我已经从中获得了一些小的性能改进，但不要指望有什么惊人的结果。

【讨论】：

感谢您的回复。是的，不幸的是，我们必须产生一种通配符方法。我一定会看看我们的一些输入的 substr 。你有任何关于你改进的指标吗？我们正在搜索超过 1000 万行，所以我的假设是一个小小的改进会产生很大的影响。
这个数字只是我们搜索的一个例子。这也可以是字符串。我也在尝试考虑这个的实现。用户可以为字符串和数字输入一个长度为 N 的字符串。我想知道我是否可以对字符串进行后期处理以执行正确的 substr。
对不起，这是在我以前的工作单位，所以我没有任何电话号码。

【解决方案3】：

您将需要一个全文索引/预标记索引，例如lucene，也是一个二解析搜索。

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

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

【讨论】：

【解决方案4】：

如果你在做一个直接的 VARCHAR 比较，即

Column LIKE 'VALUE'

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

【讨论】：