问一个SQL SELECT中有多少个表是“太多”？

EN

很多时候，你可以通过创建辅助视图来缓解视觉上的异味，我不认为有一个硬性的规则来说明有多少连接被认为是不好的。

与过程化编码不同，将SQL拆分成小块可能会导致查询效率低下。

SQL Optimiser可以很好地处理大量的表连接，如果你遇到了特殊情况，你可以使用提示来指定连接顺序或样式。在现实中，我认为连接超过10个表的查询是非常罕见的，但这在报告类型的场景中发生是非常可行的。

如果您发现有很多连接，并且发现这个特定的查询是一个瓶颈，并且您拥有所有正确的索引，那么您可能需要重构。但是，请记住，大量连接可能只是症状，而不是问题的根本原因。应该遵循查询优化的标准实践(查看探查器、查询计划、数据库结构、逻辑等)。

SQL Server仍然使用tempdb进行合并联接，因此通常不需要仅仅为了重构单个SELECT查询而创建临时表。

这真的取决于你的表有多大，即使你只将两个表连接在一起，如果它有1亿条记录，那么这将是一个缓慢的过程。

如果你在表a中有X条记录，在表b中有Y条记录，如果你将它们连接在一起，你可能会得到最多x*y条记录，在这种情况下，交换内存将在过程中使用，这将是缓慢的，相比较而言，较小的查询只使用具有最佳性能的CPU L2缓存。

但是，如果你觉得真的需要连接很多表来实现这个目标，我建议你的数据库是过度标准化的，第三标准化在大多数情况下工作得很好，不要试图吐出太多的信息，因为它被认为是低效的查询。

是的，如果需要，请创建一个表来缓存繁重查询的结果，并仅在必要时更新字段，甚至一天只更新一次。

我也看到庞大的查询连接7-10个表，但从我所看到的情况来看，查询优化器似乎总是找到最有效的计划-当然，我在这些类型的复杂问题中看到的所有性能问题通常都与一些其他问题有关(例如条件WHERE语句或嵌套子查询)