如何计算一个数据库表上的简单选择查询的成本？

Question

员工（姓名、职务、dname、地址） 都是相同长度的字符串字段。

ename 属性是候选键。 该关系包含 10,000 页。 有 10 个缓冲页。

查询是： 选择 E.title，E.ename 来自员工 E WHERE E.title=‘管理员’

假设只有 10% 的 Employee 元组满足选择条件。

假设 ename 上的聚集 B+ 树索引（唯一索引）可用。最佳计划的成本是多少？

我将如何计算这笔费用？如果标题上有一个聚集的 B+ 树索引，我将如何计算？

另一个查询： 选择 E.ename 来自员工 E WHERE E.title=‘管理员’ AND E.dname=‘财务’

假设只有 10% 的 Employee 元组满足条件 E.title ='Administrator'，只有 10% 满足 E.dname ='Finance'，只有 5% 满足这两个条件。

假设一个聚集的 B+ 树索引是（唯一的）可用的。最佳计划的成本是多少？

专家！请帮忙。任何 cmets/建议将不胜感激。我想了解整个过程。我做了很多研究，我想我知道如何计算每个操作的成本，让我困惑的是他们说关系包含 10,000 页而不是说每页中有多少个元组？根据我所学到的，我相信我们必须以元组的形式获得关系的总大小，对吗？为什么？

感谢任何花时间阅读问题的人:-)

Answer 1

如果没有合适的索引，查询将进行表扫描。由于读取行是执行时间的主要部分（在许多情况下）；你提到的变化无关紧要。

如果您确实有相关索引，并且该索引具有足够的选择性（10% 可能是“足够选择性”），查询将分为两个步骤：

1. 扫描索引的部分，这是一个单独的BTree。
2. 对于每一行，从该 BTree 获取PRIMARY KEY（假设您使用的是 InnoDB）。使用该 PK，在主 BTree 中查找包含 PK 和数据的行。

如果所有必要的块都缓存在 buffer_pool 中（同样，假设 InnoDB），成本的变化相当小。

如果不是所有块都在缓存中（因为 mysqld 刚刚启动，或者因为索引/数据太大而无法保持缓存），那么您将进入“计算磁盘命中数”。这是因为“成本”的主要部分是 I/O。现在计算成本是相当复杂的，因为需要知道已经缓存了多少百分比，查询是否会“破坏”缓存，这 10% 是否均匀分散，或者聚集在一起，或者介于两者之间。

由于（对于 InnoDB），PK 与数据“聚集”在一起，因此通过 PK 查找的行为与通过辅助键查找不同。

10K 行是“小”。 10 个缓冲页——你是什么意思？ “所有都是相同长度的字符串字段”——使用CHAR 而不是VARCHAR 是不切实际的，也不是一个好主意。无论如何，字符串长度对这个讨论几乎没有影响。

WHERE E.title=‘Administrator’ AND E.dname=‘Finance’ -- 请求INDEX(title, dname) 按任一顺序。

“经验法则”：一个块 (InnoDB) 可以容纳 100 行（数据或索引）。 （当然，这可能会有很大差异。但有时它对于“计算磁盘命中数”很方便。）

在我的cookbook 中，我发现更容易专注于设计“最佳”索引，而无需计算“成本”。

关于查询的进一步说明

“假设只有 10% 的 Employee 元组满足条件 E.title ='Administrator'，只有 10% 满足 E.dname ='Finance'，只有 5% 满足这两个条件。”对于 MySQL，这里有更多细节：

案例 1：INDEX(title) -- 类似于第一次查询 -- 索引范围扫描 10%，然后探查数据。
案例 2：INDEX(dname) -- 同上。
案例 3：两个索引 - slim 有可能使用“索引合并相交”来执行两个索引“范围扫描”，将两个集合合并在一起，然后进入行的数据。
案例 4（最好）：INDEX(title, dname)（或相反的顺序）：返回索引范围扫描，但仅限于 5% 的项目。

MySQL 的首选引擎是 InnoDB。我所讨论的假设不是 MyISAM。使用 InnoDB，“数据”存储在 B+Tree 中，每个二级索引也是如此。在考虑如何执行查询时，请记住这种相似性。另请注意，二级索引的“叶节点”包含 PK，从而提供了查找记录其余部分的机制。