我对SQL没有太多经验。我写的大多数查询都非常小。每当我看到一个非常大的查询时，我总是认为它需要进行优化。但这是真的吗？或者是否存在真正需要大量查询的情况？
当我说大型查询时，我的意思是超过1000个字符的查询答案 0 :(得分：6)
是的，任何陈述，方法甚至查询都可能“太大”。
问题在于，实际上定义的是太大。
如果您无法坐下来在相对较短的时间内弄清楚查询的作用，最好将其分解为更小的块。
我总是喜欢从维护的角度来看问题。如果查询现在很难理解，如果你必须在其中调试一些内容呢？
仅仅因为你看到一个大型查询，并不意味着它需要被改变或优化，但如果它对于它自己的好处太复杂，那么你可能想要考虑重构。
答案 1 :(得分：3)
与其他语言一样，您无法根据字符数确定查询的效率。另外，1000个字符不是我称之为“大”的字符，特别是当你使用好的表/列名，有意义的别名等时。
如果您对SQL不够熟悉以便能够“关注”特定查询的设计优点，请通过分析器运行它并检查执行计划。这会让你很好地了解问题，如果有的话，有问题的代码会受到影响。
我的经验法则是：尽可能地编写最好，最紧凑，最强大，最简单的代码，并在需要的地方进行优化 - 也就是说，在哪里看到性能瓶颈或在哪里（经常发生）你打了一针你自己在头上说“D'OH！”在大约三点钟的假期。
摘要：编码良好，并根据需要进行优化。
罗伯特说，如果你不能轻易说出查询在做什么，可能需要简化。
答案 2 :(得分：1)
如果您习惯于编写简单的东西，您可能没有意识到获取复杂报告的信息有多复杂。是的，查询可能变得冗长而复杂，并且仍然可以很好地满足他们的要求。通常，用于对某些内容进行性能调整的技术可能会使那些不太熟悉高级查询技术的代码看起来更复杂。重要的是执行所需的时间以及它是否返回正确的数据，而不是它有多少个字符。
当我看到一个复杂的查询时，我首先想到的是它是否会返回开发人员真正打算返回的内容（你会惊讶于答案的频率是多少）然后我会看看它是否可以表现调整。是的，那里有很多写得很糟糕的长查询，但是也有很多或者更多的人在没有重大数据库重新设计或更快的硬件的情况下尽可能快地做他们想要做的事情。
答案 3 :(得分：0)
我建议不应该测量查询大小/复杂度的字符。
我把它归结为：
答案 4 :(得分：0)
在我工作的地方，我们创建了超过1000个字符的存储过程。我不能说这是必要的，但有时候速度胜过效率（最明显的是当客户需要快速修复时）。
话虽如此......如果有时间，我会尝试优化查询，因为它可以获得小而高效，而不会过于混乱。我已经使用了嵌套的存储过程来使事情变得更加清晰和/或起作用。
答案 5 :(得分：0)
字符数并不意味着需要优化查询 - 这是 那些字符。
在子查询之上的子查询之类的东西是我要查看的内容。我也会审查JOIN，但是与ERD相比，不应该花很长时间才能知道是否存在不必要的JOIN - 我要看的第一件事就是连接哪些表但是没有在输出中使用，这是如果表是link / corrollary / etc表，则很好。