我执行一个简单的查询：
SELECT * FROM TABLE1
WHERE ID > 9 AND ID < 11
查询详细计划为：
[SPU顺序扫描表"TABLE1"｛(TABLE1."ID")｝]
--估计行数=1。。。
但是在将where子句更改为之后
WHERE ID = 10
查询详细计划更改：
[SPU顺序扫描表"TABLE1"｛(TABLE1."ID")｝]
--估计行数=1000。。。
(其中1000是TABLE1中的总行数)。
为什么会这样？估算是如何工作的？
任何基于成本的数据库的优化器总是充满惊喜，这在我熟悉的平台上并不罕见。
有几个问题：-你在桌子上做了统计数据吗？(否则你会盲目飞行)-该列的数据类型是什么？(我希望它是某种整数，而不是NUMBER(x，y)，即使y=0)
此外：netezza中某列的统计数据不包含分布统计数据(它不知道在一个包含5年数据的支持系统表中，"已解决"的案例是否多于"未解决"的病例)。相反，它依赖于两件事：1) 对于所有表：如果您创建了它们，则进行简单统计(不同值的数量、最大值+最小值、null的数量)2) 对于大型表(我认为可配置的最小值接近100 mill行)，它通过扫描数据列表上的几个随机数据页来创建JIT系统(Just In Time)，这些数据页都符合区域可映射的where子句，并为这一查询创建统计信息。
最后一个功能实际上非常强大，尽管它将运行时添加到了查询的规划阶段。它显著增加了这样一种可能性，即如果表上的两个where子句之间存在某种相关性，就会将其考虑在内。一个例子：一个大城市所有公民名单中的where子句(年龄>60，退休=true)。增加年龄限制可能或多或少是无关紧要的，Netezza会知道这一点。
一般来说，你不应该担心netezza的估计行数有点偏离(在这种情况下)，它通常会"足够正确"，并在问题上投入硬件来弥补任何小错误。
直到最近，我还在使用SQLserver，它对where子句的值过于乐观(在新版本中可能更好)，在连接6个表时，最终出现了5级嵌套循环连接的访问计划，每个嵌套循环连接中有数百万行。像您在问题中所做的那样更改where子句，将导致sqlserver对特定限制的同情减少，这可能会导致5个联接成为更高效的HASH或其他算法，从而获得更好的性能。根据我的经验，在过于依赖这些估计的数据库上，这种情况发生得太频繁了——也许是因为优化器没有针对类似仓库的工作负载创建/调整。