在大多数情况下，您可以通过计数磁盘寻道来估算查询性能。对于小表，您通常可以在一个磁盘寻道中找到一行（因为索引可能被缓存）。对于更大的表，您可以估算，使用 B 树索引，您需要这么多次寻道来找到一行：log(行数) / log(索引块长度 / 3 * 2 / (索引长度 + 数据指针长度)) + 1。

在 MySQL 中，索引块通常为 1,024 字节，数据指针通常为四字节。对于一个 50 万行表，键值长度为三个字节（MEDIUMINT 的大小），公式表明 log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 次寻道。

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

但是，对于写操作，您需要四个寻道请求来找到新索引值的位置，并且通常需要两个寻道来更新索引和写入行。

前面的讨论并不意味着您的应用程序性能会随着 N 的增长而逐渐下降。只要一切都被操作系统或 MySQL 服务器缓存，事情就会变得只有一点慢。直到数据变得太大无法缓存，事情就会变得非常慢，直到您的应用程序仅受磁盘寻道（其增加速度为 log N）的限制。为了避免这种情况，请随着数据的增长增加键缓存的大小。对于 MyISAM 表，键缓存的大小由 key_buffer_size 系统变量控制。请参阅 第 7.1.1 节，“配置服务器”。