Equi加入的特殊情况

我遇到了使用特殊形式的equi加入的特殊脚本。Equi加入的特殊情况

SELECT * 
FROM 
per_assignments a, per_assigment_types b 
WHERE 
a.assignment_status_type_id + 0 = b.assignment_status_type_id

为什么在equi中加入了零加入？我开始意识到它与避免索引搜索有关，但仍然可以解释一下完整的图片。在此先感谢

编辑：

这不是这是关系到表/列的声明。据我所知，这与SQL调优有关。

这是我发现： -

这是在较小的表使用。
不像通常那样进行索引搜索，而是一次搜索完整的表格。

但我真的不知道到底有什么区别，正常的等连接，而且索引如何影响性能。

如果有人可以在特定的环境中描述并且让我知道我的发现是否是错误的，那将会非常有帮助。感谢您的时间和精力一样:-)

列说明：

分配状态类型标识的两个表中被声明为NUMBER（9）

来源

2011-05-09 NirmalGeo

请提供您的表格声明（至少为相关字段） – Spudley 2011-05-09 13:06:22

我已更新，均声明为NUMBER（9） – NirmalGeo 2011-05-09 13:27:21

原因杀死指数使用对于小桌子来说就是表现。当您使用索引执行连接时，需要两个磁盘I/O来读取数据。一个读取索引，另一个读取全表中的数据。对于较小的表，读取整个表并执行全表扫描比执行第二个磁盘I/O的速度更快。

这是一个广泛的泛化，并且可能会随时变化，即使在您的数据库中。理论上，SQL优化器应该足够聪明，可以识别这种情况，即使没有提示，也可以使用全表扫描查找索引。如果您将数据添加到一个或两个表中，也可能会将更快的性能从全表扫描转换为索引查找。

我有关于调整这些疑问将是问题：

什么是表的准确定义，包括如何充分是VARCHAR列（如果有的话），平均？
每个表中有多少行？
每天有多少行添加到每张表中？
此查询执行的频率如何？
有没有人计时他们查询执行与两个选项，看哪个更快？

我担心这个查询是作为一个聪明的性能增强来写的，无论是对于早期版本的数据库，还是只是作为一个聪明的黑客而没有意识到查询优化器可以做得更好或更好的工作。

来源

2011-05-09 13:37:18

谢谢Thomas，真是一个很好的发现。我真的不知道磁盘I/O部分，如果可能的话，你介意分享一个相同的链接/参考吗？谢谢。 – NirmalGeo 2011-05-10 05:43:48

使用+0而不是NO_INDEX提示使得这看起来更像货物崇拜编程而不是聪明的黑客。另外，您可能需要查看Richard Foote撰写的这些文章，解释索引如何可以比非常小的表的全表扫描更好：http://en.wordpress.com/tag/small-indexes/基本上，一个非常小的索引（或索引组织表）可以放在与表相同的空间中，并且所需的开销比全表扫描要少。 – 2011-05-10 15:23:01

Equi加入的特殊情况

回答

相关问题