我目前正在尝试优化我们的后端是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语句的任何好文章，讨论，视频等等？
答案 0 :(得分：1)
我认为Number被编入索引？ Teradata使用散列进行索引，因此equals将导致使用索引，而like会导致全表扫描。
如果你真的需要使用喜欢的东西，你可以做的事情并不多。您可以尝试的一件事是使用Substr(Number, 1, 3) = '123'而不是Number LIKE '123%'。过去我从中获得了很小的性能改进，但是不要指望有什么壮观的。
答案 1 :(得分：1)
您需要全文索引/预标记化索引，例如lucene，还有两个解析搜索。
e.g。向数据库插入“12345”时，请创建从“1”，“12”，“123”，“234”......等到“12345”的链接。
然后，当使用找到类似“123 **”的东西时，从查找表中找到“123”并寻找记录“12345”
答案 2 :(得分：1)
如果您正在进行直接VARCHAR比较，即
Column LIKE 'VALUE'
然后您可以尝试在该列上使用NUSI。确保收集表的主索引和索引
的统计信息答案 3 :(得分：1)
由于该列被定义为VARCHAR并且您正在使用LIKE运算符，因此您无法使用PI进行单个AMP访问。请记住，主要索引的第一项工作是在系统中的AMP之间分配数据。因为您对PI使用LIKE运算符，优化程序必须执行“全AMP”操作以满足LIKE运算符。
WHERE MyPIColumn LIKE '123%'
以123开头的值的散列可以并且最终会在多个AMP上进行。
WHERE MyPIColum = '123'
123的散列将每个记录放在同一个AMP上。查询“123”将始终是单个AMP操作。
对此进行统计可能对行估计有所帮助，但可能不会消除“所有AMP”操作。