我没有太多的 SQL 经验。我写的大多数查询都非常小。每当我看到一个非常大的查询时，我总是认为它需要优化。但这是真的吗？还是在某些情况下只需要非常大的查询？
顺便说一句，当我说大型查询时，我指的是超过 1000 多个字符的查询
【问题讨论】：
标签： sql database optimization
是的，任何语句、方法甚至查询都可能“太大”。
问题实际上是定义太大到底是什么。
如果您不能坐下来在相对较短的时间内弄清楚查询的作用，最好将其分解成更小的块。
我总是喜欢从维护的角度来看待事物。如果现在查询很难理解，如果你必须在其中调试一些东西怎么办？
仅仅因为您看到一个大查询，并不意味着它需要更改或优化，但如果它本身太复杂，那么您可能需要考虑重构。
【讨论】：
就像在其他语言中一样，您无法根据字符数来确定查询的效率。此外，1000 个字符不是我可以称之为“大”的，尤其是当您使用好的表/列名称、有意义的别名等时。
如果您对 SQL 不够熟悉，无法“观察”特定查询的设计优点，请通过分析器运行它并检查执行计划。这会让你对问题有一个很好的了解，如果有的话，有问题的代码会受到影响。
我的经验法则是：尽可能编写最好、最紧凑、最简单的代码，并在需要的地方进行优化 - 即在哪里发现性能瓶颈或在哪里（经常发生）你打耳光自己在脑海中说“D'OH！”假期凌晨三点左右。
总结：编写好代码，并在需要的地方进行优化。
正如 Robert 所说，如果您无法轻松判断查询在做什么，则可能需要对其进行简化。
【讨论】：
如果您习惯于编写简单的东西，您可能不会意识到获取复杂报告的信息可能有多么复杂。是的，查询可能会变得冗长而复杂，但对于他们被要求做的事情仍然表现良好。通常，用于性能调整的技术可能会使代码对于那些不太熟悉高级查询技术的人来说看起来更复杂。重要的是执行需要多长时间以及是否返回正确的数据，而不是它有多少字符。
当我看到一个复杂的查询时，我的第一个想法是它是否返回了开发人员真正打算返回的内容（您会惊讶于答案是否经常出现），然后我看看它是否可能性能调整。是的，那里有许多写得不好的长查询，但也有很多或更多的查询在不重新设计大型数据库或更快的硬件的情况下尽可能快地完成他们想要做的事情。
【讨论】：
我建议不是字符应该衡量查询的大小/复杂性。
我将其归结为：
【讨论】：
在我工作的地方，我们创建了超过 1000 个字符的存储过程。我真的不能说这是必要的，但有时匆忙胜过效率（尤其是当客户需要快速修复时）。
话虽如此......如果有时间我会尝试优化查询，使其尽可能小/高效，而不会过于混乱。我使用了嵌套存储过程来使事情更清晰和/或功能更丰富。
【讨论】：
字符数并不意味着需要优化查询 - 这是您看到 在这些字符中所做的。
诸如子查询之上的子查询之类的东西是我会审查的。我也会查看 JOIN，但是与 ERD 相比应该不需要很长时间才能知道是否存在不必要的 JOIN - 我首先要看的是哪些表已连接但未在输出中使用，即如果表格是链接/推论/等表格，那很好。
【讨论】：