數據庫優化是一項很復雜的工作，因為這最終需要對系統優化的很好理解才行。盡管對系統或應用系統的了解不多的情況下優化效果還不錯，但是如果想優化的效果更好，那麼就需要對它了解更多才行。
1、優化概述
讓系統運行得快得最重要因素是數據庫基本的設計。並且還必須清楚您的系統要用來做什麼，以及存在的瓶頸。
最常見的系統瓶頸有以下幾種：
磁盤搜索。它慢慢地在磁盤中搜索數據塊。對現代磁盤來說，平時的搜索時間基本上小於10毫秒，因此理論上每秒鐘可以做100次磁盤搜索。這個時間對於全新的新磁盤來說提高的不多，並且對於只有一個表的情況也是如此。加快搜索時間的方法是將數據分開存放到多個磁盤中。
磁盤讀/寫。當磁盤在正確的位置上時，就需要讀取數據。對現代磁盤來說，磁盤吞吐量至少是10-20MB/秒。這比磁盤搜索的優化更容易，因為可以從多個媒介中並行地讀取數據。
CPU周期。數據存儲在主內存中(或者它已經在主內存中了)，這就需要處理這些數據以得到想要的結果。
內存帶寬。當CPU要將更多的數據存放在CPU緩存中時，主內存的帶寬就是瓶頸了。在大多數系統中，這不是常見的瓶頸，不過也是要注意的一個因素。
1.1 MySQL設計的局限性
當使用MyISAM存儲引擎時，MySQL會使用一個快速數據表鎖以允許同時多個讀取和一個寫入。這種存儲引擎的最大問題是發生在一個單一的表上同時做穩定的更新操作及慢速查詢。如果這種情況在某個表中存在，可以使用另一種表類型。
MySQL可以同時在事務及非事務表下工作。為了能夠平滑的使用非事務表(發生錯誤時不能回滾)，有以下幾條規則：
所有的字段都有默認值
如果字段中插入了一個"錯誤"的值，比如在數字類型字段中插入過大數值，那麼MySQL會將該字段值置為"最可能的值"而不是給出一個錯誤。數字類型的值是0，最小或者最大的可能值。字符串類型，不是空字符串就是字段所能存儲的最大長度。
所有的計算表達式都會返回一個值而報告條件錯誤，例如 1/0 返回 NULL。
這些規則隱含的意思是，不能使用MySQL來檢查字段內容。相反地，必須在存儲到數據庫前在應用程序中來檢查。
1.2 應用設計的可移植性
由於各種不同的數據庫實現了各自的SQL標准，這就需要我們盡量使用可移植的SQL應用。查詢和插入操作很容易就能做到可移植，不過由於更多的約束條件的要求就越發困難。想要讓一個應用在各種數據庫系統上快速運行，就變得更困難了。
為了能讓一個復雜的應用做到可移植，就要先看這個應用運行於哪種數據庫系統之上，然後看這些數據庫系統都支持哪些特性。每個數據庫系統都有某些不足。也就是說，由於設計上的一些妥協，導致了性能上的差異。
可以用MySQL的 crash-me 程序來看選定的數據庫服務器上可以使用的函數，類型，限制等。crash-me 不會檢查各種可能存在的特性，不過這仍然是合乎情理的理解，大約做了450次測試。一個crash-me 的信息類型的例子就是，它會告訴您如果想使用Informix 或 DB2的話，就不能使字段名長度超過18個字符。
crash-me 程序和MySQL基准使每個准數據庫都實現了的。可以通過閱讀這些基准程序是怎麼寫的，自己就大概有怎樣做才能讓程序獨立於各種數據庫這方面的想法了。這些程序可以在MySQL源代碼的 `sql-bench' 目錄下找到。他們大部分都是用Perl寫的，並且使用DBI接口。由於它提供了獨立於數據庫的各種訪問方式，因此用DBI來解決各種移植性的問題。
如果您想努力做到獨立於數據庫，這就需要對各種SQL服務器的瓶頸都有一些很好的想法。例如，MySQL對於 MyISAM 類型的表在檢索以及更新記錄時非常快，但是在有並發的慢速讀取及寫入記錄時卻有一定的問題。作為Oracle來說，它在訪問剛剛被更新的記錄時有很大的問題(直到結果被刷新到磁盤中)。事務數據庫一般地在從日志表中生成摘要表這方面的表現不怎麼好，因為在這種情況下，行記錄鎖幾乎沒用。
為了能讓應用程序真正的做到獨立於數據庫，就必須把操作數據的接口定義的簡單且可擴展。由於C++在很多系統上都可以使用，因此使用C++作為數據庫的基類結果很合適。
如果使用了某些數據庫獨有的特定功能(比如 REPLACE 語句就只在MySQL中獨有)，這就需要通過編寫替代方法來在其他數據庫中實現這個功能。盡管這些替代方法可能會比較慢，但是它能讓其他數據庫實現同樣的功能。
在MySQL中，可以在查詢語句中使用 /*! */ 語法來增加MySQL特有的關鍵字。然而在很多其他數據庫中，/**/ 卻被當成了注釋(並且被忽略)。
如果有時候更高的性能比數據結果的精確更重要，就像在一些Web應用中那樣，這可以使用一個應用層來緩存結果，這可能會有更高的性能。通過讓舊數據在一定時間後過期，來合理的更新緩存。這是處理負載高峰期時的一種方法，這種情況下，可以通過加大緩存容量和過期時間直到負載趨於正常。
這種情況下，建表信息中就要包含了初始化緩存的容量以及正常刷新數據表的頻率。一個實現應用層緩存的可選方案是使用MySQL的查詢緩存(query cache)。啟用查詢緩存後，數據庫就會根據一些詳情來決定哪些結果可以被重用。它大大簡化了應用程序。
2、優化 SELECT 語句及其他查詢
首先，影響所有語句的一個因素是：您的權限設置越復雜，那麼開銷就越大。使用比較簡單的 GRANT 語句能讓MySQL減少在客戶端執行語句時權限檢查的開銷。例如，如果沒有設定任何表級或者字段級的權限，那麼服務器就無需檢查 tables_priv 和 columns_priv 表的記錄了。同樣地，如果沒有對帳戶設定任何資源限制的話，那麼服務器也就無需做資源使用統計了。如果有大量查詢的話，花點時間來規劃簡單的授權機制以減少服務器權限檢查的開銷是值得的。
如果問題處在一些MySQL特定的表達式或者函數上，則可以通過 MySQL 客戶端程序使用 BENCHMARK() 函數做一個定時測試。它的語法是：BENCHMARK(loop_count,expression)。例如：
所有的MySQL函數都應該被最優化，不過仍然有些函數例外。BENCHMARK() 是一個用於檢查查詢語句中是否存在問題的非常好的工具。
