資料表結構是否正確？特別是，資料行是否具有正確的資料類型，且每個資料表是否都具有適合工作類型的適當資料行？例如，執行頻繁更新的應用程式通常具有許多資料行較少的資料表，而分析大量資料的應用程式通常具有較少資料行較多的資料表。

是否已放置正確的索引以使查詢有效率？

您是否為每個資料表使用適當的儲存引擎，並利用您使用的每個儲存引擎的優點與功能？特別是，交易式儲存引擎 (例如 InnoDB) 或非交易式儲存引擎 (例如 MyISAM) 的選擇對於效能與可擴展性非常重要。

每個資料表是否都使用適當的資料列格式？此選擇也取決於資料表使用的儲存引擎。特別是，壓縮資料表會使用較少的磁碟空間，因此讀取與寫入資料所需的磁碟 I/O 較少。壓縮適用於具有 InnoDB 資料表的所有類型的工作負載，以及適用於唯讀 MyISAM 資料表。

應用程式是否使用適當的鎖定策略？例如，盡可能允許共用存取，以便資料庫作業可以並行執行，並在適當時要求獨佔存取，以便關鍵作業獲得最高優先順序。同樣地，儲存引擎的選擇非常重要。InnoDB 儲存引擎會處理大部分鎖定問題，而無需您的參與，進而允許資料庫中更好的並行性，並減少程式碼的實驗與微調量。

是否已正確調整用於快取的記憶體區域的大小？也就是說，要夠大以保留頻繁存取的資料，但不能太大而使實體記憶體過載並導致分頁。要設定的主要記憶體區域是 InnoDB 緩衝池與 MyISAM 金鑰快取。

磁碟搜尋。磁碟尋找資料需要時間。對於現代磁碟，平均時間通常低於 10 毫秒，因此理論上我們每秒可以執行約 100 次搜尋。這個時間隨著新磁碟的出現而緩慢改進，並且很難針對單一資料表進行最佳化。最佳化搜尋時間的方法是將資料分佈到多個磁碟上。

磁碟讀取和寫入。當磁碟處於正確位置時，我們需要讀取或寫入資料。對於現代磁碟，一個磁碟至少提供 10–20MB/s 的輸送量。這比搜尋更容易最佳化，因為您可以從多個磁碟平行讀取。

CPU 週期。當資料位於主記憶體中時，我們必須處理它才能獲得結果。與記憶體容量相比，擁有大型資料表是最常見的限制因素。但是，對於小型資料表來說，速度通常不是問題。

記憶體頻寬。當 CPU 需要的資料超出 CPU 快取的容量時，主記憶體頻寬會成為瓶頸。對於大多數系統來說，這是一個不常見的瓶頸，但需要注意。