Netezza：WHERE 子句如何影响查询详细计划中的估计行数？
Netezza: How does the WHERE clause influence the estimated rows number in query verbose plan?
我执行一个简单的查询：
SELECT * FROM TABLE1
WHERE ID > 9 AND ID < 11
查询详细计划是：
[SPU Sequential Scan table "TABLE1" {(TABLE1."ID")}]
-- Estimated Rows = 1, ...
但是在将where子句更改为
之后
WHERE ID = 10
查询详细计划更改：
[SPU Sequential Scan table "TABLE1" {(TABLE1."ID")}]
-- Estimated Rows = 1000, ...
（其中 1000 是 TABLE1 中的总行数）。
为什么会这样？估算是如何工作的？
任何 cost-based 数据库的优化器总是充满惊喜，在我熟悉的平台上，这个优化器并不罕见。
几个问题：
- 您是否在 table 上创建了统计信息？ （否则你就瞎了）
- 该列的数据类型是什么？ （我希望它是某种整数，而不是 NUMBER(x,y)，即使 y=0）
此外：
netezza 中某列的统计信息不包含分布统计信息（它不知道在 support-system table 5 年的情况下是否有 "solved" 多于 "unsolved" 个案例数据）。相反，它依赖于两件事：
1) 对于所有 tables：如果您创建它们，则为简单统计信息（不同值的数量、最大+最小值、空值的数量）
2) 对于大 tables（我认为可配置的最小值接近 100 行）它通过扫描数据切片上的一些随机数据页来创建 JIT syatistics（及时） zone-mappable whereclauses 并为这个查询创建统计信息。
最后一个功能实际上非常强大，尽管它为查询的 planning-phase 添加了运行时。如果 table 上的两个 whereclauses 之间存在某种相关性，这将显着增加可能性，这将被考虑在内。
一个例子：在一个主要城市的所有公民的列表中关于 (AGE>60 and Retired=true) 的 whereclause。添加 AGE 限制很可能或多或少无关紧要，Netezza 会知道这一点。
一般来说，您不必担心 netezza 的估计行数有点偏差（如本例），它通常会得到它 "right enough" 并投入硬件解决问题以补偿任何问题小错误。
直到最近，我一直在使用 SQLserver，它因对 where 子句的值过于乐观而臭名昭著（在较新的版本中可能更好），并最终在具有 5 个 nested-loop 连接级别的访问计划中结束加入 6 table 时，每行数百万行。像您在问题中所做的那样更改 where 子句，将导致 sqlserver 对特定限制进行 LESS empathes，这可能导致 5 个连接成为更高效的 HASH 或其他算法，从而获得更好的性能。根据我的经验，在数据库中过于依赖这些估计的情况太频繁了——也许是因为优化器不是 created/tuned 用于 warehouse-like 工作负载。
我执行一个简单的查询：
SELECT * FROM TABLE1
WHERE ID > 9 AND ID < 11
查询详细计划是：
[SPU Sequential Scan table "TABLE1" {(TABLE1."ID")}]
-- Estimated Rows = 1, ...
但是在将where子句更改为
之后WHERE ID = 10
查询详细计划更改：
[SPU Sequential Scan table "TABLE1" {(TABLE1."ID")}]
-- Estimated Rows = 1000, ...
（其中 1000 是 TABLE1 中的总行数）。
为什么会这样？估算是如何工作的？
任何 cost-based 数据库的优化器总是充满惊喜，在我熟悉的平台上，这个优化器并不罕见。
几个问题： - 您是否在 table 上创建了统计信息？ （否则你就瞎了） - 该列的数据类型是什么？ （我希望它是某种整数，而不是 NUMBER(x,y)，即使 y=0）
此外： netezza 中某列的统计信息不包含分布统计信息（它不知道在 support-system table 5 年的情况下是否有 "solved" 多于 "unsolved" 个案例数据）。相反，它依赖于两件事： 1) 对于所有 tables：如果您创建它们，则为简单统计信息（不同值的数量、最大+最小值、空值的数量） 2) 对于大 tables（我认为可配置的最小值接近 100 行）它通过扫描数据切片上的一些随机数据页来创建 JIT syatistics（及时） zone-mappable whereclauses 并为这个查询创建统计信息。
最后一个功能实际上非常强大，尽管它为查询的 planning-phase 添加了运行时。如果 table 上的两个 whereclauses 之间存在某种相关性，这将显着增加可能性，这将被考虑在内。 一个例子：在一个主要城市的所有公民的列表中关于 (AGE>60 and Retired=true) 的 whereclause。添加 AGE 限制很可能或多或少无关紧要，Netezza 会知道这一点。
一般来说，您不必担心 netezza 的估计行数有点偏差（如本例），它通常会得到它 "right enough" 并投入硬件解决问题以补偿任何问题小错误。
直到最近，我一直在使用 SQLserver，它因对 where 子句的值过于乐观而臭名昭著（在较新的版本中可能更好），并最终在具有 5 个 nested-loop 连接级别的访问计划中结束加入 6 table 时，每行数百万行。像您在问题中所做的那样更改 where 子句，将导致 sqlserver 对特定限制进行 LESS empathes，这可能导致 5 个连接成为更高效的 HASH 或其他算法，从而获得更好的性能。根据我的经验，在数据库中过于依赖这些估计的情况太频繁了——也许是因为优化器不是 created/tuned 用于 warehouse-like 工作负载。