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