Question

例如，现在我有一个类似的查询：

select * from A1 left join A2 on A1.Column1 = A2.Column1
left join A3 on A1.Column2 = A3.Column2 
left join A4 on A1.Column3 = A4.Column3 
....
left join A20 on A1.Column4 = A20.Column4

当我查看上述查询的执行计划时，SQL Server显示它将首先离开与A2的连接A1，然后继续左连接结果与A3 ...并且在左连接20个表之后，估计的行数没有' t改变了（2,1百万）

但是，如果我将查询更改为：

select * from A1 left join A2 on Cast(A1.Column1 as bigint) = Cast(A2.Column1 as bigint)
left join A3 on Cast(A1.Column2 as bigint) = Cast(A3.Column2 as bigint)
left join A4 on Cast(A1.Column3 as bigint) = Cast(A4.Column3 as bigint)
....
left join A20 on Cast(A1.Column4 as bigint) = Cast(A20.Column4 as bigint)

注意：我的所有列都可以强制转换为bigint，因为它只包含数字，但有时它的前导为零，所以我必须让它的数据类型为varchar。

现在，通过此查询，SQL服务器显示它将首先将A3与A3连接，然后与A4，A6，A7，A8，A10 ... A20然后A2，A17 ...关于估计的行数，在连接13个表之后，估计的行数没有改变，但在那之后，每次它加入另一个表时，估计的行数会急剧增加，从2百万增加到2,6然后3,8 ..并且在加入20个表之后它变成了8300万。

有人可以解释为什么会这样吗？在我的第二个查询中，为什么Sql server会随机连接表呢？什么可以使估计的行数突然增加？

Answer 1

完全有可能你的演员表混淆了查询优化器的统计数据 - 因为字符串排序'201'将介于'2'和'3'之间 - 而对于bigint则不会。所以，同样地，如果你有一个从'1000'到'2'的字符串范围 - 那么作为一个bigint范围没有多大意义。

我会强烈考虑存储整数版本的数据，以便存储的统计信息有意义，然后您可能会从查询优化器中获得更好的值。

SQL Server执行计划和估计的行数

1 个答案: