在大多數情況下，您可以透過計算磁碟搜尋次數來估計查詢效能。對於小型資料表，您通常可以在一次磁碟搜尋中找到一列（因為索引可能已快取）。對於較大的資料表，您可以估計使用 B 樹索引時，需要以下次數的搜尋才能找到一列： log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1。

在 MySQL 中，索引區塊通常為 1,024 個位元組，而資料指標通常為四個位元組。對於具有 500,000 列且金鑰值長度為三個位元組（MEDIUMINT 的大小）的資料表，公式指出 log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 次搜尋。

此索引將需要約 500,000 * 7 * 3/2 = 5.2MB 的儲存空間（假設典型的索引緩衝填入率為 2/3），因此您可能在記憶體中有大部分的索引，因此只需要一兩次呼叫即可讀取資料以找到列。

但是，對於寫入，您需要四次搜尋要求才能找到放置新索引值的位置，並且通常需要兩次搜尋才能更新索引並寫入列。

先前的討論並不表示您的應用程式效能會緩慢地隨著 log N 而降低。只要所有內容都由 OS 或 MySQL 伺服器快取，隨著資料表變得越來越大，速度只會稍微變慢。在資料變得太大而無法快取之後，速度會開始變慢得多，直到您的應用程式僅受磁碟搜尋（會隨著 log N 而增加）的限制。若要避免這種情況，請隨著資料的增加而增加金鑰快取大小。對於 MyISAM 資料表，金鑰快取大小由 key_buffer_size 系統變數控制。請參閱第 7.1.1 節，「設定伺服器」。