優化硬件
如果你需要龐大的數據庫表(> 2G)，你應該考慮使用64位的硬件結構，像Alpha、Sparc或即將推出的IA64。因為MySQL內部使用大量64位的整數，64位的CPU將提供更好的性能。對大數據庫，優化的次序一般是RAM、快速硬盤、CPU能力。更多的內存通過將最常用的鍵碼頁面存放在內存中可以加速鍵碼的更新。如果不使用事務安全(transaction-safe)的表或有大表並且想避免長文件檢查，一台UPS就能夠在電源故障時讓系統安全關閉。據庫存放在一個專用服務器的系統，應該考慮1G的以太網。延遲與吞吐量同樣重要。優化磁盤配備一個專用磁盤，如果確是進行很多修改工作，將更新日志和事務日志放在專用磁盤上。低尋道時間對數據庫磁盤非常重要。對與大表，你可以估計你將需要log(行數)/log(索引塊長度/3*2/(鍵碼長度 + 數據指針長度))+1次尋到才能找到一行。對於有500000行的表，索引Mediun int類型的列，需要log(500000) / log(1024/3*2/(3 + 2))+1=4次尋道。上述索引需要500000*7*3/2=5.2M的空間。實際上，大多數塊將被緩存，所以大概只需要1-2次尋道。
然而對於寫入（如上），你將需要4次尋道請求來找到在哪裡存放新鍵碼，而且一般要2次尋道來更新索引並寫入一行。對於非常大的數據庫，你的應用將受到磁盤尋道速度的限制，隨著數據量的增加呈N log N數據級遞增。將數據庫和表分在不同的磁盤上。在MySQL中，你可以為此而使用符號鏈接。條列磁盤(RAID 0)將提高讀和寫的吞吐量。帶鏡像的條列(RAID 0+1)將更安全並提高讀取的吞吐量。寫入的吞吐量將有所降低。不要對臨時文件或可以很容易地重建的數據所在的磁盤使用鏡像或RAID(除了RAID 0)。在Linux上，在引導時對磁盤使用命令hdparm -m16 -d1以啟用同時讀寫多個扇區和DMA功能。這可以將響應時間提高5~50%。在Linux上，用async (默認)和noatime掛載磁盤(mount)。對於某些特定應用，可以對某些特定表使用內存磁盤，但通常不需要。
優化操作系統
不要交換區。如果內存不足，增加更多的內存或配置你的系統使用較少內存。不要使用NFS磁盤(會有NFS鎖定的問題)。增加系統和MySQL服務器的打開文件數量。(在safe_MySQLd腳本中加入ulimit -n #)。增加系統的進程和線程數量。如果你有相對較少的大表，告訴文件系統不要將文件打碎在不同的磁道上(Solaris)。使用支持大文件的文件系統(Solaris)。選擇使用哪種文件系統。在Linux上的Reiserfs對於打開、讀寫都非常快。文件檢查只需幾秒種。
選擇應用編程接口
PERL可在不同的操作系統和數據庫之間移植。適宜快速原型。應該使用DBI/DBD接口。
PHP比PERL易學。使用比PERL少的資源。通過升級到PHP4可以獲得更快的速度。
C MySQL的原生接口。較快並賦予更多的控制。低層，所以必須付出更多。
C++較高層次，給你更多的時間來編寫應用。仍在開發中
ODBC運行在Windows和Unix上。幾乎可在不同的SQL服務器間移植。較慢。MyODBC只是簡單的直通驅動程序，比用原生接口慢19%。有很多方法做同樣的事。很難像很多ODBC驅動程序那樣運行，在不同的領域還有不同的錯誤。問題成堆。Microsoft偶爾還會改變接口。不明朗的未來。(Microsoft更推崇OLE而非ODBC)
JDBC理論上可在不同的操作系統何時據庫間移植。可以運行在web客戶端。
Python和其他可能不錯，可我們不用它們。
優化應用
應該集中精力解決問題。在編寫應用時，應該決定什麼是最重要的：速度、操作系統間的可移植性、SQL服務器間的可移植性、使用持續的連接。緩存應用中的數據以減少SQL服務器的負載。不要查詢應用中不需要的列。
不要使用SELECT * FROM table_name...測試應用的所有部分，但將大部分精力放在在可能最壞的合理的負載下的測試整體應用。通過以一種模塊化的方式進行，你應該能用一個快速“啞模塊”替代找到的瓶頸，然後很容易地標出下一個瓶頸。
如果在一個批處理中進行大量修改，使用LOCK TABLES。例如將多個UPDATES或DELETES集中在一起。應該使用可移植的應用Perl DBI/DBD、ODBC、JDBC、Python(或其他有普遍SQL接口的語言)你應該只使用存在於所有目的SQL服務器中或可以很容易地用其他構造模擬的SQL構造。www.MySQL.com上的Crash-me頁可以幫助你。
為操作系統/SQL服務器編寫包裝程序來提供缺少的功能。
如果你需要更快的速度，你應該：找出瓶頸(CPU、磁盤、內存、SQL服務器、操作系統、API或應用)並集中全力解決。使用給予你更快速度/靈活性的擴展。
