我已经看到很多问题，询问用户如何优化他们的查询，因为他们的速度太慢，即使他们的持续时间不到一秒钟。试图理解定义慢查询的内容，我发现这个question表示用户抱怨的任何内容。
这是有道理的，但它不是万无一失的。如果前端用户不知道更好，那么可能会忽略糟糕的非优化查询。我也理解查询的速度可以根据上下文而改变。
查询速度有经验法则吗？例如，让我们说我可以在50毫秒内查询一万亿条记录（编号），但我有另一个查询需要50毫秒才能查询100条记录。显然，一个是有效的，但两者对于前端用户都是相同的。是否有类似于可以应用于SQL查询的Big-O表示法？
答案 0 :(得分：5)
优化应该基于用户对数据访问的要求，而不是基于好看与否的抽象概念。
在我看来，对于正在进行的应用程序，您应首先编写查询以用于维护目的 - 您将如何在6个月后修复，维护和理解代码？ 2年后？如果您无法维护代码，那么优化就是一场持续的噩梦。我并不主张编写低效的代码，并且在性能方面肯定有一些最佳/更好的实践（例如避免MySQL中不必要的具体化子查询）。但是，了解正在发生的事情往往比长期更重要，而不是下一个软件路径可能不再需要的优化。一些优化查询的技术可能与此目标直接冲突。许多其他人都会很好地支持它。
其次，当性能开始下降时，您必须决定投资更多或更好的硬件与更改软件之间的平衡。无论如何，某些更改（例如添加适当的索引或对大型表进行分区）都是非常可取的。其他更改（例如创建由触发器维护的汇总表）会增加复杂性并且可能不太理想。
简而言之，性能是满足用户要求的。如果您的系统满足这些要求，您可以担心其他问题。如果您无需担心，