在大多數情況下，您可以透過計算磁碟搜尋次數來估算查詢效能。對於小型資料表，您通常可以在一次磁碟搜尋中找到一列（因為索引可能已快取）。對於較大的資料表，您可以使用 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 緩慢退化。只要所有內容都由作業系統或 MySQL 伺服器快取，隨著資料表變大，速度只會稍微變慢。在資料變得太大而無法快取後，速度會開始變慢得多，直到您的應用程式僅受磁碟搜尋限制（磁碟搜尋會以 log N 增加）。為了避免這種情況，請隨著資料的增長而增加金鑰快取大小。對於 MyISAM 資料表，金鑰快取大小由 key_buffer_size 系統變數控制。請參閱 第 7.1.1 節，「設定伺服器」。