SQL 查询 - 太慢有多慢？

Posted 2023-03-22

【中文标题】SQL 查询 - 太慢有多慢？

【英文标题】：SQL Queries - How Slow is Too Slow?

【发布时间】：2009-01-19 08:57:03

【问题描述】：

对于可合理实现的 SQL 查询速度，您有任何正式或非正式的标准吗？你如何执行它们？假设一个生产 OLTP 数据库在每秒几十个查询的完全实际生产负载下，正确配备和配置。

用于说明目的的个人示例（非推荐，高度取决于许多因素，有些超出您的控制范围）：

期望：

每个事务单元（单个语句、从开始到结束事务边界的多个 SQL 语句或单个存储过程，以最大者为准）必须在平均 1 秒或更短时间内执行，并且没有异常异常值。

分辨率：

较慢的查询必须优化为标准。报告和其他分析的慢查询被移至 OLAP 多维数据集（最佳情况）或静态快照数据库。

（显然某些执行查询（插入/更新/删除）无法移动，因此必须进行优化，但到目前为止，根据我的经验，这是可以实现的。）

【参考方案1】：

鉴于您不能期望系统上的确定性性能（至少在理论上）会受到瞬时负载峰值的影响，因此您希望性能 SLA 是概率性的。这方面的一个例子可能是：

95% 的交易可在 2 秒内完成。 95% 的搜索查询（更适合搜索屏幕）在 10 秒内完成。 95% 的运营报告可在 10 秒内完成。

事务和搜索查询无法从事务系统中移出，因此您可以采取的唯一措施是调整数据库或应用程序，或者购买更快的硬件。

对于运营报告，您需要对符合运营报告的条件毫不留情。只有绝对需要访问最新数据的报告才应该在实时系统之外运行。执行大量 I/O 的报告在生产系统上是非常反社会的，并且规范化的模式对于报告来说往往效率很低。将不需要实时数据的任何报告转移到数据仓库或其他一些单独的报告设施中。

【参考方案2】：

在编写/重构存储过程时，我通常遵循一秒规则，尽管我的工作场所对此没有任何具体规则。这只是我的常识。经验告诉我，如果执行一个不执行任何大容量插入的过程需要 10 秒或更长时间，那么代码中通常会出现严重问题，很容易纠正。

我在性能不佳的 SP:s 中遇到的最常见问题是不正确地使用索引，从而导致代价高昂的索引查找操作。

【参考方案3】：

N 的 O 是好的，像 N^2 这样更糟糕的东西最终会太慢。