1. 從軟體本身和它運行的典型工作負載來看，MySQL通常也更適合運行在廉價硬體上

2. 基本資源

2.1. CPU

2.2. 記憶體

2.3. 磁碟

2.4. 瓶頸

2.5. 網路資源

3. CPU

3.1. 最常見的瓶頸是CPU耗盡

3.2. 檢查CPU使用率來確定工作負載是否受CPU限制

3.3. 低延遲（快速響應時間）

3.3.1. 需要更快的CPU，因為每個查詢將只使用一個CPU

3.4. 高吞吐量

3.4.1. 如果可以同時運行多個查詢，那麼可以使用多個CPU為查詢提供服務

4. 記憶體

4.1. 記憶體耗盡的情況也會發生，但通常只在你試圖將太多記憶體分配給MySQL時才會發生

4.2. 配置大記憶體的主要原因並不是為了在記憶體中保存大量數據，而是為了避免磁碟I/O

4.3. 磁碟I/O比訪問記憶體中的數據要慢幾個數量級

4.4. 如果有足夠的記憶體，可以完全避開磁碟讀取操作

4.5. 如果所有數據都能裝入記憶體，那麼一旦伺服器的緩存預熱完成，每次讀取都將是一次緩存命中

4.6. 寫入可以像讀取一樣在記憶體中執行，但遲早必須被寫入磁碟，才能持久保留數據

4.7. 緩存可以延遲寫操作，但緩存不能像消除讀操作那樣消除寫操作

4.8. 多次寫操作，一次刷新

4.8.1. 一個數據片段可以在記憶體中被多次更改，而無須每一次都將新值寫入磁碟

4.8.2. 當數據被最終刷新到磁碟時，自上次物理寫入以來發生的所有修改都將被持久化

4.9. I/O合併

4.9.1. 許多不同的數據片段可以在記憶體中被修改，這些修改可以被收集在一起，因此物理寫可以作為單個磁碟操作執行

4.9.2. 提前寫日誌（write-ahead logging）策略

4.9.2.1. 允許在記憶體中更改頁面，而不用將更改刷新到磁碟，這通常涉及隨機I/O，速度非常慢

4.9.2.2. 將更改的記錄寫入順序日誌文件，這樣要快得多

4.9.2.3. 後臺線程可以稍後將修改過的頁面刷新到磁碟，這樣做可以優化寫操作的性能

4.10. 寫操作從緩衝中獲益，因為可以將隨機I/O轉換為順序I/O

4.11. 非同步（緩衝）寫操作通常由操作系統處理，並且是被成批處理的，因此可以更優地被刷新到磁碟

4.12. 同步（無緩衝）寫入必須等待數據落盤

5. 固態（快閃記憶體）存儲

5.1. I/O飽和也會發生，但比CPU耗盡的頻率低得多

5.2. 用HDD硬碟時，最好嘗試找到一個有效的記憶體/磁碟比率

5.2.1. HDD延遲較高、IOPS較低

5.3. 使用SSD時，記憶體對磁碟的比率就變得不那麼重要了

5.4. 固態設備對於提高伺服器整體性能非常有用，現在通常應該成為資料庫的標準配置，尤其對於OLTP工作負載

5.4.1. SSD通常比HDD快10到20倍

5.4.2. 只有在預算極為有限的系統中，或者在需要驚人的高達數PB的磁碟空間的數據倉庫場景下，才考慮繼續使用HDD

5.5. 比硬碟驅動器明顯更好的隨機讀寫性能

5.6. 快閃記憶體設備讀的能力通常略好於寫的能力

5.7. 比硬碟驅動器更好的順序讀寫性能

5.8. 比硬碟驅動器更好的併發支持

5.8.1. 只有在擁有大量併發性的情況下，快閃記憶體設備才能真正實現最高吞吐量

5.9. 固態存儲設備使用非易失性快閃記憶體晶元組成的單元

5.9.1. 非易失隨機訪問記憶體（NVRAM）

5.10. 固態存儲建立在快閃記憶體之上

5.11. 快閃記憶體的特點

5.11.1. 可以被快速地多次讀取，而且以很小的單元讀取數據

5.11.2. 寫入則要困難得多

5.11.2.1. 只有進行特殊的擦除操作之後，存儲單元才能被重新寫入數據，並且每次擦除的塊大小較大

5.12. 寫操作的限制是固態存儲複雜性的原因

5.12.1. 為了使寫操作能夠很好地執行，並避免過早地耗盡快閃記憶體塊寫壽命，設備必須能夠重新定位頁面，並執行垃圾收集和所謂的損耗均衡

5.13. 為了使某些塊保持新鮮併為新的寫入做好準備，設備會回收塊

5.14. 100GB文件在160GB的SSD上的性能與在320GB的SSD上的性能是不同的

5.14.1. 當沒有空閑塊時，必須等待擦除操作完成，從而導致速度減慢

5.14.2. 寫入空閑塊需要幾百微秒，但擦除速度要慢得多，通常需要幾毫秒

6. RAID

6.1. 存儲引擎通常將數據/索引保存在單個大文件中，這意味著RAID通常是存儲大量數據的最佳選項

6.2. 不要認為RAID是數據安全方面的強有力的保證

6.2.1. RAID並不能消除，甚至不能減少備份的需要

6.3. 保存在損壞的物理媒介中的數據很少被訪問，可能幾個月都不會被髮現，直到嘗試讀取數據，或者當另一個驅動器出現故障，RAID控制器嘗試使用損壞的數據重建陣列時才發現問題

6.3.1. 硬碟空間越大，出現這種情況的可能性就越大

6.4. 大多數控制器都提供了一些軟體來報告陣列的狀態，你需要對此進行跟蹤，否則可能完全不知道驅動器已出現故障

6.4.1. 到第二個驅動器出現故障時就太晚了

6.5. 通過定期主動檢查陣列的一致性，可以降低潛在的損壞風險

6.6. 很多RAID控制器不能很好地處理大數據塊

6.7. RAID緩存是物理安裝在硬體RAID控制器上的（相對）少量記憶體

6.7.1. 在RAID緩存中緩存讀取都是浪費記憶體

6.8. RAID控制器的記憶體是一種稀缺資源，應該明智地使用它

6.9. 對事務日誌發出fsync()調用，併在啟用sync_binlog的情況下創建二進位日誌，但除非控制器有備用電池單元（BBU）或其他非易失性存儲，否則不應啟用寫緩存

6.9.1. 硬碟也可能會撒謊。應該確保在fsync()時刷新緩存，或者乾脆在沒有備用電池時禁用它們

6.9.2. 當安裝新硬體時，最好進行真正的暴力碰撞測試（例如把電源插頭拔出來）。這通常是發現細微的錯誤配置或偷偷摸摸的硬碟行為的唯一方法

6.10. 要測試RAID控制器的BBU是否真的可靠，請確保將電源線拔下一段時間

6.10.1. 有些BBU設備在沒電的情況下無法維持足夠的時間（將RAID緩存的數據刷新到磁碟

6.10.2. 一個環節出問題可能會導致整個存儲系統鏈變得無用

6.11. RAID 0

6.11.1. 最便宜和性能最好的RAID配置

6.11.2. 永遠不適合用於生產資料庫

6.11.3. 在開發環境中，當伺服器完全失效也不會變成突發事件時，可以選擇RAID 0

6.11.4. 不提供任何冗餘

6.11.5. RAID 0陣列的故障概率高於任何單磁碟的故障概率，而不是更低

6.12. RAID 1

6.12.1. 良好的讀性能，並且可以跨磁碟複製數據

6.12.2. 良好的冗餘

6.12.3. 讀取速度略高於RAID 0

6.12.4. 順序寫入不需要許多底層磁碟就能執行得很好

6.12.5. 需要冗餘但只有兩個硬碟驅動器的低端伺服器的典型選擇

6.12.6. 大多數操作系統都允許你輕鬆地創建軟體RAID 0和RAID 1捲

6.13. RAID 5

6.13.1. 將數據分佈在具有分散式奇偶校驗塊的多塊磁碟上，以便在任何一塊磁碟出現故障時，可以從奇偶校驗塊重建數據

6.13.2. 如果兩塊磁碟同時出現故障，整個捲將無法恢復

6.13.2.1. 丟失兩塊磁碟時會產生災難性的後果

6.13.3. RAID 5的可伸縮性不能超過10塊磁碟

6.13.4. 良好的RAID 5的性能在很大程度上依賴於RAID控制器的緩存，這可能與資料庫伺服器的需求相衝突

6.14. RAID 6

6.14.1. 允許你在承受兩次磁碟故障的情況下仍然能重建陣列

6.14.2. 計算額外的奇偶校驗會使寫操作比RAID 5慢

6.15. RAID 10

6.15.1. 一個非常好的數據存儲選擇

6.15.2. 條帶化的鏡像對組成，因此在讀寫方面都能很好地被擴展

6.15.2.1. 最佳的條帶塊大小取決於工作負載和硬體

6.15.2.2. 對於隨機I/O來說，擁有較大的塊大小是很好的，因為這意味著可以從單個驅動器中滿足更多的讀取需求

6.15.3. 與RAID 5相比，它的重建速度快且容易

6.15.4. 以很好地在軟體中被實現

6.16. RAID 50

6.16.1. 由條帶化的RAID 5陣列組成，如果有很多磁碟，它可以很好地兼顧RAID 5的經濟性和RAID 10的性能

6.16.2. 主要用於非常大的數據集，如數據倉庫或非常大的OLTP系統

7. 網路

7.1. 延遲和帶寬是網路連接的限制因素

7.2. 網路運行不正常是主要的性能瓶頸

7.3. 數據包丟失是一個常見的問題

7.3.1. 即使是1%的丟失也足以導致性能顯著下降，因為協議棧中的各個層都會嘗試通過等待一段時間然後重新發送數據包等策略來解決問題，這會增加額外的響應時間

7.4. DNS解析異常中斷或緩慢成為一個致命弱點

7.4.1. 對於生產伺服器來說，啟用skip_name_resolve是一個好主意

7.4.2. 當MySQL收到連接請求時，它會同時進行正向和反向DNS查找

7.4.3. 如果啟用skip_name_resolve選項，MySQL不會進行任何DNS查找

7.4.3.1. 意味著用戶賬號在host列中只能有IP地址、“localhost”或IP地址通配符

7.4.3.2. host列中包含主機名的任何用戶賬號都將無法登錄

8. 文件系統

8.1. 文件系統是在資料庫中保證數據完整性的最低層

8.2. Windows

8.2.1. 只有一個（NTFS）是真正可行的

8.3. GNU/Linux

8.3.1. 大多數時候，給定的文件系統跟其他文件系統相比不會有明顯的差別

8.3.2. 只有在某些情況下，達到文件系統的處理極限時，例如，需要處理高併發性、處理許多文件、碎片，等等，不同文件系統的差異才會體現出來

8.3.3. 最好使用日誌型文件系統，如ext4、XFS或ZFS

8.3.4. 建議使用XFS文件系統，並將交換率和磁碟隊列調度器設置為適合於伺服器的值

8.4. 磁碟隊列調度器

8.4.1. 完全公平排隊，即CFQ（Complete FairQueuing）

8.4.2. 在MySQL的工作負載類型下，CFQ會導致非常糟糕的響應時間，因為會不必要地阻塞隊列中的一些請求

8.4.3. 不要使用CFQ，它可能會導致嚴重的性能問題

8.5. 記憶體和交換

8.5.1. 給MySQL分配大量記憶體後，它的表現最好

8.5.2. InnoDB使用記憶體作為緩存來避免磁碟訪問

8.5.2.1. 意味著記憶體系統的性能會直接影響查詢的速度

8.5.3. 當使用SSD時，性能損失不像使用HDD時那樣明顯

8.5.3.1. 仍然應該積極地避免交換，即使只是為了避免不必要的寫操作，因為寫操作可能會縮短磁碟整體壽命

8.5.4. 更改存儲引擎讀寫數據的方式

8.5.4.1. 設置innodb_flush_method=O_DIRECT可以減輕I/O壓力

8.5.4.2. 該參數僅對InnoDB有效

8.6. 很多技巧都是特定於內核版本的，所以要小心，特別是在升級時

8.7. Linux剖析器perf是一個非常有用的工具，可以用它來檢查操作在系統級別發生的事情