1. 改善效能
資料庫管理員把他們生命中的相當一部份時間花在了調整、試驗以改善DBMS效能之上。在診斷應用的滯緩現象和效能問題時，效能不良的資料庫（以及資料庫查詢）通常是最常見的禍因。
可以看出，下面的內容並不能完全決定MySQL的效能。只是想回顧一下前面各章的重點，提供進行效能最佳化探討和分析的一個出發點。
-
首先，MySQL（與所有DBMS一樣）具有特定的硬體建議。在學習和研究MySQL時，使用任何舊的計算機作為伺服器都可以。但對用於生產的伺服器來說，應該堅持遵循這些硬體建議。
-
一般來說，關鍵的生產DBMS應該執行在自己的專用伺服器上。
-
MySQL是用一系列的預設設定預先配置的，從這些設定開始通常是很好的。但過一段時間後你可能需要調整記憶體分配、緩衝區大小等。（為檢視當前設定，可使用
SHOW VARIABLES;和SHOW STATUS;。） -
MySQL一個多使用者多執行緒的DBMS，換言之，它經常同時執行多個任務。如果這些任務中的某一個執行緩慢，則所有請求都會執行緩慢。如果你遇到顯著的效能不良，可使用
SHOW PROCESSLIST顯示所有活動程序（以及它們的執行緒ID和執行時間）。你還可以用KILL命令終結某個特定的程序（使用這個命令需要作為管理員登入）。 -
總是有不止一種方法編寫同一條SELECT語句。應該試驗聯結、並、子查詢等，找出最佳的方法。
-
使用
EXPLAIN語句讓MySQL解釋它將如何執行一條SELECT語句。 -
一般來說，儲存過程執行得比一條一條地執行其中的各條MySQL語句快。
-
應該總是使用正確的資料型別。
-
決不要檢索比需求還要多的資料。換言之，不要用
SELECT *（除非你真正需要每個列）。 -
有的操作（包括INSERT）支援一個可選的
DELAYED關鍵字，如果使用它，將把控制立即返回給呼叫程式，並且一旦有可能就實際執行該操作。
插句題外話
-
DELAYED 的含義
在支援的 SQL 操作（如 INSERT）中，使用 DELAYED 關鍵字可以讓操作變成非同步執行。也就是說，當客戶端執行該操作時，MySQL 會：
-
立即將控制權返回給呼叫程式
- 呼叫程式（如一個應用程式或指令碼）在傳送 SQL 操作後，不需要等待操作實際完成就可以繼續執行其他任務。
-
稍後執行實際操作
- MySQL 將操作放入一個佇列中，等到目標表可用（例如當前沒有其他寫操作時），再實際執行該操作。
-
-
工作機制
-
將操作加入佇列
- 使用 DELAYED 時，INSERT 操作不會立刻鎖定目標表，而是將要插入的資料儲存在一個記憶體佇列中。
-
非同步處理
- MySQL 後臺執行緒會在目標表可用時，從佇列中取出資料並執行插入操作。
-
非阻塞操作
- 這樣呼叫程式就不用等待資料庫寫操作完成，提高了程式的響應速度。
-
-
優點
-
提升響應速度
- 對於客戶端來說，DELAYED 操作立即返回，不會因為表鎖或 I/O 等操作造成延遲。
-
適用於高併發場景
- 特別是在高併發寫入場景下，可以減少鎖競爭，提升整體系統的吞吐量。
-
-
缺點與限制
-
資料可能丟失
- 如果伺服器在佇列中的資料被實際寫入表之前崩潰，這些資料會丟失。
-
目標表的限制
- DELAYED 只支援 MyISAM 儲存引擎，不支援 InnoDB 等其他儲存引擎。
-
實時性不高
- 插入操作不是即時完成，因此對於需要實時寫入的場景不適用。
-
DELAYED 已被廢棄
從 MySQL 5.7.6 開始，DELAYED 關鍵字被廢棄，不再推薦使用。
-
迴歸正題
-
在匯入資料時，應該關閉自動提交。你可能還想刪除索引（包括
FULLTEXT索引），然後在匯入完成後再重建它們。 -
必須索引資料庫表以改善資料檢索的效能。確定索引什麼不是一件微不足道的任務，需要分析使用的SELECT語句以找出重複的WHERE和ORDER BY子句。如果一個簡單的WHERE子句返回結果所花的時間太長，則可以斷定其中使用的列（或幾個列）就是需要索引的物件。
-
你的SELECT語句中有一系列複雜的OR條件嗎？透過使用多條SELECT語句和連線它們的UNION語句，你能看到極大的效能改進。
-
索引改善資料檢索的效能，但損害資料插入、刪除和更新的效能。如果你有一些表，它們收集資料且不經常被搜尋，則在有必要之前不要索引它們。（索引可根據需要新增和刪除。）
-
LIKE很慢。一般來說，最好是使用FULLTEXT而不是LIKE。 -
資料庫是不斷變化的實體。一組最佳化良好的表一會兒後可能就面目全非了。由於表的使用和內容的更改，理想的最佳化和配置也會改變。
-
最重要的規則就是，每條規則在某些條件下都會被打破。