问题标签 [cardinality-estimation]

在数据库中，我有一列 (B)，每个元素中都有字典。

例如。（来自 B 列的一个元素）：

{“桌子”：12，“椅子”：34，“猫”：65，}

我想用 hll 计算它的基数。在查询中：

我想排除“表”在 B 列中的任何情况（我想排除“表”是键的键值对）。怎么做（有可能）？

我试图在 where 子句中添加：

但它不起作用。

在下面的示例中，Oracle 优化器的估计行错误了两个数量级。如何改进估计的行数？

对于 10 个字母 A 到 J 中的每一个，表A中的行的数字为 1 到 1,000。

表C有 100 个表的副本A。

因此，表A的基数为 10K，表 C 的基数为 1M。

对 table 中的数字的给定单值谓词A将产生 table 中行的 1/1000 A（对于 table 相同C）。

table 中字母的给定单值谓词A将产生 table 中行的 1/10 A（与table 相同C）。

设置脚本。

考虑以下查询的解释计划。

每个步骤的行基数对我来说很有意义。

ID=2 --> (1/1,000) * (1/10) * 10,000 = 1

ID=3 --> (1/1,000) * (1/10) * 1,000,000 = 100

ID=1 --> 100 是正确的。ID=2 和 ID=3 中的谓词是相同的，ID=2 的每一行在 ID=3 的行源中只有一个匹配项。

现在考虑下面稍微修改的查询的解释计划。

每个步骤 ID=2 和 ID=3 的行基数对我来说是有意义的，但现在 ID=1 错误了两个数量级。

ID=2 --> (1/1,000)(1/10) * 10,000 = 1

ID=3 --> (1/1,000)(1/10) * 1,000,000 = 100

ID=1 --> 优化器的估计与实际相差两个数量级。

添加唯一和外部约束以及扩展统计信息并没有提高估计的行数。

我需要做什么才能使估计的行更好地匹配现实？

使用 Oracle 企业版 19c。

提前致谢。

编辑 在确保使用了最新的 optimizer_features_enable 并修改了其中一个谓词之后，我们仍然有一个解释计划，其估计的行数减少了两个数量级。

ID=6 估计应该有 100 行。似乎它应用了谓词因子两次。一次用于访问，再次用于过滤器。

我的理解是，嵌套循环连接的内部行源的解释计划中的估计行数反映了该嵌套循环仅一次迭代的行数。

在以下示例中，解释计划的第 6 步是嵌套循环连接的内部行源，该连接一次通过一个 ROWID 获取行。因此，估计应该有 1 行（每个 ROWID 只有 1 行）。

为什么第 6 步table access by index ROWID显示 100（我希望它显示 1）？

使用 Oracle 19c 企业版。

外部行源步骤 3 乘以内部行源步骤 5 = 嵌套循环步骤 2。

但是，外部行源步骤 2 乘以内部行源步骤 6 <> 嵌套循环步骤 1。

我同意第 1 步的总数应该是 200，但不明白为什么第 6 步估计有 100 行。

为什么步骤 6 的估计行数为 100 而不是 1？

提前致谢。

我们已将 SQL Server 从 2014 年升级到 2019 年。

在 2014 年，这个查询很好：

升级时（没有代码更改只有 SQL Server 升级），查询杀死了它所属的进程，而不是运行 4 分钟，现在它持续了 8 小时，然后它会超时。

我们最终添加了这个：OPTION (USE HINT ( 'FORCE_LEGACY_CARDINALITY_ESTIMATION' ))到查询的末尾，然后事情又好了。

2个问题：

1. 因为我们必须使用旧版 CE，这是否意味着新版 CE 不如旧版 CE 强大？
2. 如果我们不是在WHERE子句中使用子查询，而是将两者都左连接并选择了 NOT NULL，那会消除使用 Legacy CE 的需要吗？

谢谢！