本文是Monty在O'Reilly Open Source Convention 2000大會上的演講之一，涉及我們可以且應該優化什麼、優化硬件、優化磁盤、優化操作系統、選擇應用編程接口五個方面，是篇詳盡的MySQL優化文檔
一、我們可以且應該優化什麼？
二、優化硬件
如果你需要龐大的數據庫表(>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)
ODBC
運行在Windows和Unix上。
幾乎可在不同的SQL服務器間移植。
較慢。MyODBC只是簡單的直通驅動程序，比用原生接口慢19%。
有很多方法做同樣的事。很難像很多ODBC驅動程序那樣運行，在不同的領域還有不同的錯誤。
問題成堆。Microsoft偶爾還會改變接口。
不明朗的未來。(Microsoft更推崇OLE而非ODBC)
JDBC
理論上可在不同的操作系統何時據庫間移植。
可以運行在web客戶端。
Python和其他
可能不錯，可我們不用它們。
