SQL查询-多慢就是太慢？

对于可以合理实现的SQL查询速度，您是否有任何正式或非正式的标准？你如何执行它们？假设一个生产OLTP数据库处于每秒几十个查询的完全实际生产负载下，并进行了适当的配置和配置

用于说明目的的个人示例（不是建议，高度依赖于许多因素，有些因素超出您的控制）：

期望：

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

决议：

较慢的查询必须根据标准进行优化。对报告和其他分析的慢速查询将移动到OLAP多维数据集（最佳情况）或静态快照数据库

---

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

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

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

事务性查询和搜索查询不能从事务性系统中移出，所以您只能采取数据库或应用程序调优，或者购买更快的硬件

---

对于运营报告，您需要毫不留情地对待什么是运营报告。只有绝对需要访问最新数据的报告才能从实时系统中运行。在生产系统中，执行大量I/O的报告是非常反社会的，规范化的模式对于报告来说往往效率很低。将不需要实时数据的任何报表移动到数据仓库或其他独立的报表工具。

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

---

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

O of N是好的，而像N^2这样更糟糕的操作最终会太慢