是否有一个很好的“经验法则”可以将 EXPLAIN 成本转换为（挂钟）运行时？

Question

有时，我的数据库进程的使用者会要求估计何时完成给定的任务。虽然我觉得我知道如何在大多数数据库引擎中阅读 EXPLAIN，但我很难将其翻译为“15 分钟后再次询问我”。有谁知道用于任何特定数据库的良好“经验法则”？

我意识到这不会是一个硬性规定，但在某些情况下，即使能够给出一个大概的数字也可能很有用。

Answer 1

我怀疑这不可能像你想象的那样。一个重要原因是实际运行时间非常依赖于硬件，并且数据库引擎所做的许多优化决策都是有效地平衡不同硬件组件（例如，磁盘、内存、CPU）的使用。

我建议您运行一系列与您的应用程序相关的查询，记录成本估算和运行时间，并尝试理解这些数据。您可能会得到一个很好的线性关系，或者您可能会了解到成本数字对于此目的毫无价值。

Answer 2

基于成本的优化器都通过各种专有算法工作（或者您可以为开源数据库读取它们），但它们通常通过为引用操作分配值 1 来工作。例如，在 SQL Server 中，成本估计为1 在雷德蒙德的某个开发人员办公桌下的参考计算机上花费 1/320 秒。成本计算只是对查询成本的相对猜测。许多 RDBMS 使用此成本来建立优先级，或者在死锁的情况下，终止更便宜的查询（它们再次运行所需的时间更少）。但这一切都只是基于查询优化器在运行查询时可以处理的信息的猜测。

Peter 是对的，你所能希望的最好的结果是在理想的场景中运行一些基准查询，并使用这些查询作为最佳猜测的基础。您必须在 RDBMS 中处理许多不同的争用点，因此很难具体确定任何给定查询在现实世界中的执行情况。