我目前正在学习 SQL，并且我读过连接和子查询可能会破坏性能。我(有点)了解过程编程语言中关于算法复杂性的理论，并在编程时尽量注意这一点，但我不知道不同的 SQL 查询的成本有多高。我正在决定是应该花时间了解 SQL 性能，还是在查询运行缓慢时才注意到这一点。那么我的基本问题是:SQL 的过早优化和过程语言一样邪恶吗？
作为补充信息，我在一个环境中工作，在大多数情况下，高性能不是问题，我必须使用的最大表有大约 15 万行。
这是我在说“邪恶”时引用的唐纳德·克努斯 (Donald Knuth) 的话:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
最佳答案
我想说一些关于性能的一般概念是必须的:它会阻止您编写可能损害您的应用程序的非常糟糕的查询(即使您的表中没有数百万行)。
它还将帮助您设计您的数据库，使其更加面向官方:例如，您将对放置索引的位置有一些想法。
但是您不应该将性能作为首要目标:第一件事是拥有一个有效的应用程序；然后，如果需要，您将对其进行优化(不过，在开发时了解一些性能概念将有助于您拥有一个更易于优化的应用程序)。
请注意，我不会说“对性能有概念”是“过早优化”，只要您不只是“优化”，而只是“正确编写”；我宁愿称其为有助于编写质量更好的代码的良好实践；-)
关于sql - SQL 中的过早优化是否为 "evil"，就像它在过程编程语言中一样？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2264373/