问如何查找查询所需的块传输数和查找操作

EN

好的，我已经为那些想要通过使用B+树或其他结构的索引通过数据库查询学习块传输基础的人找到了实用的解决方案。

如果没有定义用于搜索值的索引，则需要将驻留在辅助磁盘上的所有数据都转移到块和块中。因此，所有块都将被转移，值将被依次搜索。知道磁盘上数据块的地址就足够了，然后就会像我强调的那样依次搜索值。因此，根据我们的示例，在查询期间将传输15000个块。我寻求就够了。

如果在eid上有主B+树索引，那么我们可以从给定的查询中做出两个假设：

首先，B+树搜索eid=1200，它找不到值1200的eid，因为eid在0-100之间。因此，通过首先从B+树中进行搜索，保证了磁盘中没有这样的值，因此在磁盘中不存在块传递和查找。

其次，如果我们假设有100个唯一分布的eid值，其中一个是1200，那么B+树在搜索eid=1200时就会成功。在这种情况下，值1200的叶上的指针指向排序eid值的磁盘位置，指向地址是eid=1200的第一个地址。通过从这个地址开始搜索数据，直到eid不再是1200。我们的近似假设是，由于有100个唯一的开斋节值，并且有15000块。eid=1200的元组大约在15000/100 =150个块内。我们除以块的总数，因为我们知道值是排序的，因为索引是主键。因此，如果我们知道eid有其第一个1200值的地址，那么我们绝对可以肯定，只要我们没有看到eid属性有不同的值，下面的元组也会有eid=1200。因此，如果主索引为eid，那么150个块将被转移，而1 seek就足够了，因为当我们开始搜索时，没有必要再次查找磁盘，我们可以依次搜索元组，直到eid在磁盘中有不同的值。

类似地，如果我们有一个关于数量的主索引，并且我们想要的值= 31，50，我们需要传递(15000/50)*20 =6000个块。我们除以50，因为我们可以有50个不同的数值。我们把除法乘以20，因为我们将搜索这50个数值中的20个，而不是1。因此，这20个不同的数值可以是6000元组。再一次查找就足够了，当我们开始从起始地址搜索时，我们将依次查找元组。

如果索引是次要的，那么我们不能再说值是在磁盘中排序的。来自B+树的叶节点的指针指向一个桶，该桶包含指向磁盘上值的实际位置的指针。所以我们先去地址桶，然后从那里直接访问磁盘。因此，我们的第一个搜索是从B+树到桶，然后从桶到磁盘。注意，在最坏的情况下，您想要的所有值都可以放在完全不同的块中。因此，我们可能需要像包含我们定义的值的元组总数一样多地传递块。

如果存在辅助索引eid，且值介于0-100之间，则同样不会出现I/O，因为eid=1200中没有这样的值。但是，如果我们再次对eid值进行第二个假设，那么我们现在大致假设可以有1000000/100 = 10000元组，其中包含值为1200的属性eid。在最坏的情况下，如果非元组依次出现，并且在不同的块中，我们将需要传输10000个块。再次，我们将需要10000寻求找到磁盘上的位置桶所指向的。

如果有一个关于数量的二级指数，并且我们需要其中的20个，这些值大约为(1000000/50)*20 = 400000元组。在最坏的情况下，我们可能需要转移400000块，如果我们假设当一个块被传输时，下一个想要的元组永远不会在块中最后传输。对于这种情况，我们将需要，在最坏的情况下，400000块转让和400000寻求，正如我强调了上述原因。

我们可以在搜索索引量时选择eid=1200，反之亦然。因此，我们不关心第二个条件，即在搜索索引数量eid=1200时查找>= 30，或者在搜索索引eid=1200时查找>= 30。

同样，这些都是近似的，通常也是最坏的结果，以解释块传输的基础知识，并在进行查询时进行查找。它给出了如何处理从磁盘到主内存和用户的数据传输的基本概念。

虽然我投票结束这个问题，但我确实想发表一些评论太长，不能发表评论。

您的基本问题“如何计算完成查询所需的块传输和查找操作的数量?”是不确定的。这类操作的数量取决于数据库的状态。特别是，数据页和索引页是否已经缓存在内存中。

对于给出的声明，我认为世界上99.999%的人需要知道的唯一重要的事情是，payment(eid, amount, cid)上的指数是最优的指数。索引的前两个元素(按该顺序)支持where子句。最后一个允许索引覆盖查询，因此不需要使用原始数据表。具体类型的指数似乎完全不重要。