首先要清楚資料庫應用的分類，一般分為兩類：OLTP（Online Transaction Processing，線上事務處理）和OLAP（Online Analytical Processing，線上分析處理），這是兩種完全不同的資料庫應用。OLAP多用在資料倉庫或資料集市中，一般需要執行複雜的SQL語句來進行查詢；OLTP多用在日常的事物處理應用中，如銀行交易、線上商品交易、Blog、網絡遊戲等應用。相對于OLAP，資料庫的容量較小。
InnoDB存儲引擎一般都應用于OLTP的資料庫應用，這種應用的特點如下所示：
使用者操作的并發量大。
事務處理的時間一般比較短。
查詢的語句較為簡單，一般都走索引。
複雜的查詢較少。
可以看出，OLTP的資料庫應用本身對CPU的要求并不高，因為複雜的查詢可能需要執行比較、排序、連接配接等非常耗CPU的操作，這些操作在OLTP的資料庫應用中很少發生。是以，可以說OLAP是CPU密集型的操作，而OLTP是IO密集型的操作。建議在采購裝置時，應将更多的注意力放在提高IO的配置上。
此外，為了獲得更多記憶體的支援，CPU必須支援64位的應用，否則無法支援64位作業系統的安裝。是以，為新的應用選擇64位的CPU是必要的前提。現在4核的CPU已經非常普遍，而今年Intel和AMD又都推出了6核的CPU，将來随着作業系統的更新，我們還可能看到128核的CPU，這都需要資料庫更好地對其進行支援。
從InnoDB存儲引擎的設計架構上來看，其主要的背景操作都是在一個單獨的MASTER THREAD中完成的，是以并不能很好地支援多核的應用。當然，開源社群已經通過多種方法來改變這種局面，新的InnoDB Plugin版本在各種測試下已經顯示對多核CPU的處理性能有了極大的提高。是以，如果你的CPU支援多核，InnoDB Plugin是更好的選擇。另外，如果你的CPU是多核的，你可以通過修改參數innodb_read_io_threads和innodb_write_io_threads來增大IO的線程，這樣也能更充分利用CPU的多核性能。
在目前的MySQL版本中，一條SQL查詢語句隻能在一個CPU行工作，并不支援多CPU的處理。OLTP的資料庫應用操作一般都很簡單，是以對OLTP應用的影響并不是很大。但是，多個CPU或多核CPU對處理大并發量的請求還有非常有幫助的。
記憶體的大小最能直接反應資料庫的性能。InnoDB存儲引擎既緩存資料，又緩存索引，并将其緩存于一個很大的緩沖池中，我們将這個緩沖池稱為InnoDB Buffer Pool，它的大小直接影響了資料庫的性能。
Percona公司的CTO Vadim對此做了一次測試，以此反應記憶體的重要性，結果如圖所示。
在上述的測試中，資料和索引總大小為18GB，然後将緩沖池的大小分别設為2GB、4GB、6GB、8GB、10GB、12GB、14GB、16GB、18GB、20GB、22GB，再進行sysbench的測試。可以發現，随着緩沖池的增大，測試結果TPS（Transaction Per Second）會線性增長。當緩沖池增大到20GB和22GB，資料庫的性能有了極大的提高，因為這時緩沖池的大小已經大于資料檔案本身的大小，所有對資料檔案的操作都可以在記憶體中進行，是以這時的性能應該是最優的，再調大緩沖池并不能再提高資料庫的性能。是以，應該在開發應用前預估“活躍”資料庫的大小可能會是多少，并以此确定資料庫伺服器記憶體的大小。當然，要使用更多的記憶體，還必須使用64位的作業系統。
如何判斷目前資料庫的記憶體是否已經達到瓶頸了呢？可以通過檢視目前伺服器的狀态，比較實體磁盤的讀取和記憶體讀取的比例來判斷緩沖池的命中率，通常InnoDB存儲引擎的緩沖池的命中率不應該小于99%，如：
show global status like 'innodb%read%'\G
上述參數的具體含義如下所示：
Innodb_buffer_pool_reads：表示從實體磁盤讀取頁的次數。
Innodb_buffer_pool_read_ahead：預讀的次數。
Innodb_buffer_pool_read_ahead_evicted：預讀的頁，但是沒有被讀取就從緩沖池中被替換的頁的數量，一般用來判斷預讀的效率。
Innodb_buffer_pool_read_requests：從緩沖池中讀取頁的次數。
Innodb_data_read：總共讀入的位元組數。
Innodb_data_reads：發起讀取請求的次數，每次讀取可能需要讀取多個頁。
以下公式可以計算各種對緩沖池的操作：
從上面的例子看，緩沖池命中率=66946 /(66946+0+713）=99.92%，可見目前記憶體的壓力并不是很大。
即使緩沖池的大小已經大于資料庫檔案的大小，這也不意味着沒有磁盤操作。資料庫的緩沖池隻是一個用來存放熱點的區域，背景的master線程還負責将髒頁異步地寫入磁盤，每次事務送出時還需要立即寫入重做日志檔案。