今天乙個朋友向我諮詢怎麼去優化 mysql，我按著思維整理了一下，大概粗的可以分為21個方向。 還有一些細節東西（table cache, 表設計，索引設計，程式端快取之類的）先不列了，對乙個系統，初期能把下面做完也是乙個不錯的系統。
1. 要確保有足夠的記憶體
資料庫能夠高效的執行，最關建的因素需要記憶體足更大了，能快取住資料，更新也可以在記憶體先完成。但不同的業務對記憶體需要強度不一樣，一推薦記憶體要佔到資料的15-25%的比例，特別的熱的資料，記憶體基本要達到資料庫的80%大小。
2. 需要更多更快的cpu
mysql 5.6可以利用到64個核，而mysql每個query只能執行在乙個cpu上，所以要求更多的cpu，更快的cpu會更有利於併發。
3. 要選擇合適的作業系統
在官方建議估計最推薦的是solaris, 從實際生產中看centos, rehl都是不錯的選擇，推薦使用centos, rehl 版本為6以後的，當然oracle linux也是乙個不錯的選擇。雖然從mysql 5.5後對windows做了優化，但也不推薦在高併發環境中使用windows.
4. 合理的優化系統的引數
更改檔案控制代碼 ulimit –n 預設1024 太小
程序數限制 ulimit –u 不同版本不一樣
禁掉numa numctl –interle**e=all
5. 選擇合適的記憶體分配演算法
預設的記憶體分配就是c的malloc 現在也出現許多優化的記憶體分配演算法:
jemalloc and tcmalloc
從mysql 5.5後支援宣告內儲存方法。
[mysqld_safe]
malloc-lib = tcmalloc
或是直接指到so檔案
[mysqld_safe]
malloc-lib=/usr/local/lib/libtcmalloc_minimal.so
6. 使用更快的儲存裝置ssd或是固態卡
儲存介質十分影響mysql的隨機讀取，寫入更新速度。新一代儲存裝置固態ssd及固態卡的出現也讓mysql 大放異彩，也是**在去ioe中乾出了乙個漂亮仗。
7. 選擇良好的檔案系統
推薦xfs, ext4,如果還在使用ext2,ext3的同學請盡快公升級別。 推薦xfs，這個也是今後一段時間linux會支援乙個檔案系統。
檔案系統強烈推薦: xfs
8. 優化掛載檔案系統的引數
掛載xfs引數：
(rw, noatime,nodiratime,nobarrier)
掛載ext4引數：
ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)
如果使用ssd或是固態盤需要考慮：
innodb_page_size = 4k
innodb_flush_neighbors = 0
9. 選擇適合的io排程
正常請下請使用deadline 預設是noop
echo dealine >/sys/block//queue/scheduler
10. 選擇合適的raid卡cache策略
請使用帶電的raid，啟用writeback， 對於加速redo log ,binary log, data file都有好處。
11. 禁用query cache
query cache在innodb中有點雞肋，innodb的資料本身可以在innodb buffer pool中快取，query cache屬於結果集快取，如果開啟query cache更新寫入都要去檢查query cache反而增加了寫入的開銷。
在mysql 5.6中query cache是被禁掉了。
12. 使用thread pool
13. 合理調整記憶體
連線可以用thread_cache_size快取，觀查屬於比較屬不如thread pool給力。資料庫在連上分配的記憶體如下：
max_used_connections * (
read_buffer_size +
read_rnd_buffer_size +
join_buffer_size +
sort_buffer_size +
binlog_cache_size +
thread_stack +
2 * net_buffer_length …
要把60-80%的記憶體分給innodb_buffer_pool_size. 這個不要超過資料大小了，另外也不要分配超過80%不然會利用到swap.
14. 合理選擇log重新整理機制
redo logs:
– innodb_flush_log_at_trx_commit = 1 // 最安全
– innodb_flush_log_at_trx_commit = 2 // 較好效能
– innodb_flush_log_at_trx_commit = 0 // 最好的情能
binlog :
binlog_sync = 1 需要group commit支援，如果沒這個功能可以考慮binlog_sync=0來獲得較佳效能。
資料檔案：
innodb_flush_method = o_direct
15. 請使用innodb表
如果你還在myisam請考慮快速轉換。
16. 設定較大的redo log
以前percona 5.5和官方mysql 5.5比拼效能時，勝出的乙個tips就是分配了超過4g的redo log ,而官方mysql5.5 redo log不能超過4g. 從 mysql 5.6後可以超過4g了，通常建redo log加起來要超過500m。 可以通過觀查redo log產生量，分配redo log大於一小時的量即可。
17. 優化磁碟的io
innodb_io_capactiy 在sas 15000轉的下配置800就可以了，在ssd下面配置2000以上。
在mysql 5.6:
innodb_lru_scan_depth = innodb_io_capacity / innodb_buffer_pool_instances
innodb_io_capacity_max = min(2000, 2 * innodb_io_capacity)
18. 使用獨立表空間
目前來看新的特性都是獨立表空間支援:
truncate table 表空間**
表空間傳輸
較好的去優化碎片等管理效能的增加，
整體上來看使用獨立表空間是沒用的。
19. 配置合理的併發
innodb_thread_concurrency =併發這個引數在innodb中變化也是最頻繁的乙個引數。不同的版本，有可能不同的小版本也有變動。一般推薦：
在使用thread pool 的情況下：
innodb_thread_concurrency = 0 就可以了。
如果在沒有thread pool的情況下：
5.5 推薦：innodb_thread_concurrency =16 – 32
5.6 推薦innodb_thread_concurrency = 36
20. 優化事務隔離級別
預設是 repeatable read
推薦使用read committed binlog格式使用mixed或是row
較低的隔離級別 = 較好的效能
21. 注重監控
任環境離不開監控，如果少了監控，有可能就會陷入盲人摸象。 推薦zabbix+mpm構建監控。
文章**：
優化mysql的21個建議 MySQL優化小建議
mysql優化小建議 洛逸發布於 2019 11 04 12 03 背景 那啥，你過來一下！怎麼了？我 都單元測試了的，沒出問題啊！我一臉懵逼跑到運維大佬旁邊。你看看！你看看！多少條報警，趕快優化一下！運維大佬簡訊列表裡面50多條mysql cpu 100 報警簡訊。再看看專案名稱不就是我前幾天剛發...
mysql優化建議
1.建立 2.sql編寫mysql欄位型別 資料型別 含義date 3位元組，日期，格式 2014 09 18 time 3位元組，時間，格式 08 42 30 datetime 8位元組，日期時間，格式 2014 09 18 08 42 30 timestamp 4位元組，自動儲存記錄修改的時間 ...
MySQL優化建議
設計資料表的時候要遵守三正規化，但是不要嚴格遵守。可以適度打破正規化。乙個表字段不適合過多。常用表中只要保留常用的字段 盡量給每個字段新增not null 根據表的特點來選擇合適的表引擎，如果這個表經常被寫，應該選擇innodb,但是mysql5.6一般都是選擇innodb 根據表存放的資料來決定字...