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

在 MySQL 中，索引块通常为 1,024 字节，数据指针通常为 4 字节。对于具有 500,000 行和键值长度为 3 字节（MEDIUMINT 的大小）的表，该公式表明 log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 次查找。

此索引将需要存储大约 500,000 * 7 * 3/2 = 5.2MB 的数据（假设典型的索引缓冲区填充率为 2/3），因此您可能在内存中拥有大部分索引，因此只需要一次或两次调用读取数据来找到行。

但是，对于写入操作，您需要进行四次查找请求才能找到放置新索引值的位置，通常需要进行两次查找来更新索引并写入行。

前面的讨论并不意味着您的应用程序性能会随着 log N 的增长而缓慢下降。只要所有内容都由操作系统或 MySQL 服务器缓存，随着表变大，事情只会变得稍微慢一些。当数据变得太大而无法缓存时，事情就会开始变得慢得多，直到您的应用程序仅受磁盘查找（以 log N 增长）的限制。为了避免这种情况，请随着数据增长而增加键缓存大小。对于 MyISAM 表，键缓存大小由 key_buffer_size 系统变量控制。请参阅 第 7.1.1 节，“配置服务器”。