您是否有合理可行的SQL查询速度的正式或非正式标准？你是如何执行它们的？假设生产OLTP数据库在每秒几十个查询的完全实际生产负载下，正确配置和配置。
用于说明目的的个人示例（不是推荐，非常取决于许多因素，有些因素超出您的控制范围）：
期望：
每个事务单元（单个语句，从开始到结束事务边界的多个SQL语句，或单个存储过程，以最大者为准）必须在1秒或更短时间内执行，没有异常异常值。
分辨率：
较慢的查询必须优化为标准。报告和其他分析的慢查询将移至OLAP多维数据集（最佳情况）或静态快照数据库。
（显然有些执行查询（插入/更新/删除）无法移动，因此必须进行优化，但根据我的经验，这是可以实现的。）
答案 0 :(得分：5)
鉴于您无法预期系统上的确定性性能（至少在理论上）会受到瞬态负载峰值的影响，您希望性能SLA具有概率性。这方面的一个例子可能是：
95％的交易在2秒内完成 95％的搜索查询（更适合搜索屏幕）在10秒内完成 95％的运营报告将在10秒内完成。
交易和搜索查询无法从事务系统移出，因此您可以采取的唯一操作是数据库或应用程序调整，或购买更快的硬件。
对于运营报告，您需要对有资格作为运营报告的内容表示无情。只有绝对需要访问最新数据的报告才能在实时系统上运行。执行大量I / O的报告在生产系统上非常反社交，规范化模式往往对报告效率很低。将任何不需要实时数据的报告移到数据仓库或其他单独的报告工具中。
答案 1 :(得分：1)
在编写/重构存储过程时，我通常遵循一秒规则，尽管我的工作场所没有任何特定的规则。这只是我的常识。经验告诉我，如果执行一个程序需要10秒或更长时间，而不执行任何大型批量插入，代码中通常会出现严重问题，可以轻松纠正。
他们在SP中遇到的最常见问题：性能不佳的问题是索引的使用不正确，导致代价高昂的索引搜索操作。
答案 2 :(得分：1)
N的N是好的，任何比N ^ 2更糟的东西最终都会太慢。