通常情况下，您可以通过计算磁盘寻找次数来估计查询性能。对于小表，可以在一个磁盘寻找中找到一行记录（因为索引可能已经缓存在内存中）。对于大表，使用B树索引，可以估计需要多少次寻找来找到一行：log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1.

在 MySQL 中，索引块通常是1024字节，数据指针通常是四个字节。对于500,000行表，其中键值长度为三个字节（MEDIUMINT），公式计算结果为log(500,000)/log(1024/3*2/(3+4)) + 1 = 4次寻找。

这个索引需要存储约500,000 * 7 * 3/2 = 5.2MB（假设典型的索引缓冲区填充率为2/3），所以您可能已经将大部分索引加载到内存中，需要只读取数据一次或两次来找到行记录。

然而，对于写操作，您需要四次寻找来找到新索引值的位置，并且通常需要两次寻找来更新索引和写入行记录。

前面的讨论不意味着您的应用程序性能会因日志N而逐渐下降。只要一切都被操作系统或 MySQL 服务器缓存，事情只会变得很慢，直到数据太大不能被缓存时才开始明显变慢，然后您的应用程序将被磁盘寻找限制（磁盘寻找时间增加为日志N）。为了避免这个问题，可以随着数据增长增加键缓存大小。对于MyISAM表，键缓存大小由key_buffer_size系统变量控制。见第7.1.1节，“配置服务器”。