在大多数情况下，您可以通过计算磁盘查找来估计查询性能。对于小型表，您通常可以在一次磁盘查找中找到一行（因为索引可能已缓存）。对于较大的表，您可以估计使用 B-Tree 索引，需要执行以下次数的查找才能找到一行：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 节，“配置服务器”.