我目前正在学习SQL，我已经读到了连接和子查询可能会破坏性能。我（有点）了解程序化编程语言中的算法复杂度理论并尝试在编程时注意这一点，但我不知道不同的SQL查询费用高昂的程度。我正在决定是否应该投资时间学习关于SQL性能的知识或者只有在我的查询运行缓慢时才注意到它。对我来说，基本问题是：SQL的过早优化与过早优化对程序化语言一样那么邪恶吗？
顺便提一下，我工作的环境大多数情况下不需要考虑高性能，我需要处理的最大表格有大约15万行。
以下是唐纳德·克努斯(Donald Knuth)的一句话："我们应该忘记小效率，即大约97%的时间：过早的优化是万恶之源，然而我们不应该放弃那重要的3%机会。"
它还可以帮助您设计数据库以更加注重效率：例如，您将有一些关于在哪里放置索引的想法。
但是，您不应该将性能作为首要目标：首要的是拥有一个可运行的应用程序；然后，如果需要，您可以对其进行优化（尽管在开发时具有一些性能概念将有助于您更轻松地优化应用程序）。
请注意，我不会说“了解性能概念”是“过早优化”，只要您不仅仅“优化”，而是正确编写代码；我更愿意将其称为有助于编写更高质量代码的良好实践;-)
Knuth的意思是：了解SQL优化真的非常重要，但只有在需要时才需要。正如你所说，“大多数情况下……高性能不是问题。”
只有在那3%的时间里，当您需要高性能时，了解什么规则可以打破以及为什么很重要。
然而，与过程性语言不同，即使对于150k行，了解查询的处理方式也可能很重要。例如，与在索引列上搜索精确匹配相比，自由文本搜索将非常缓慢。这是进入例如分片或完全去规范化的最后一步，大多数数据库管理员和开发人员会划清界限。
我认为你应该尽可能使SQL易于阅读，只有当它影响到你时才考虑性能。
话虽如此。
在开发过程中要注意标准事项，例如索引、子查询、使用游标等，如果标准查询可以完成工作，则不必使用这些。
正确地开发原始代码不会有害，需要时可以优化问题。
编辑
还要记住，SQL代码的可维护性非常重要，而调试SQL比普通编码稍微困难一些。
我不认为SQL优化有像过早进行编程优化那样多的陷阱。提前考虑性能设计模式和查询可以帮助您避免以后一些非常恶心的重新设计。话虽如此，如果该查询不是慢查询、可以缓存或很少以影响应用程序的方式调用，则花一天时间消除表扫描可能对您毫无价值。
我个人会分析我的查询并专注于最糟糕的和最常用的查询。提前仔细设计可以消除大部分最糟糕的情况。
我同意这里所说的一切，并且我想补充一点：确保你的SQL被封装得很好，这样当你发现需要优化的地方时，只需要更改一个地方，而且更改对调用它的任何代码都是透明的。
个人而言，我喜欢将所有的SQL封装在PL/SQL过程中，但也有一些人不同意。无论你做什么，我建议尽量避免将你的SQL“内联”到其他源代码中。这似乎总是导致剪切和粘贴，并很快变得难以维护。将你的SQL放在其他地方，并尽可能地重复使用它。
此外，了解索引的工作原理，以及何时应该使用它们和何时不应该使用它们。很多人第一反应，当他们得到一个慢查询时，就是将表索引到死。这可能在短期内解决问题，但长期来看，过度索引的表会变得插入和更新缓慢。选择几个恰当的索引比索引每个字段要好得多。尝试阅读Stephane Faroult的《重构SQL应用程序》。
最后，正如上面所说，一个正确规范化的数据库设计将有助于避免99%的慢查询。有时候需要反规范化，但在打破规则之前了解规则非常重要。
祝你好运！
