為什麼要調整引數
不同伺服器之間的配置，效能不一樣
不同業務場景對資料的需求不一樣
mysql的預設引數只是個參考值，並不適合所有的應用場景
優化之前我們需要知道什麼
伺服器相關的配置
業務相關的情況
mysql相關的配置
伺服器相關的配置
硬體情況
作業系統版本
cpu,網絡卡節電模式
伺服器numa設定---記憶體分片，cpu對應記憶體；
raid卡快取
磁碟排程策略--write back
資料寫入cache即返回，資料非同步的從cache刷入儲存介質
磁碟排程策略--write through
資料同時寫入cache和儲存介質才返回寫入成功
write back 效能高於 write through
而write through 的安全性更高。
raid
raid --廉價的儲存陣列
簡單就是將多塊盤當做一塊盤來使用；容量是多盤的和，效能也是多盤之和；
問題，就是當其中一塊盤損壞後，無法保證其資料的安全性；
raid1
指兩塊盤做相互的映象--達到高可用
問題，只能使用兩塊盤來做，儲存空間 有限制
raid5
至少使用三塊盤，總儲存空間只有兩塊；因為它需要儲存校驗資料塊；
高可用的實現，是通過校驗資料塊，來恢復資料；
侷限，只能壞一塊盤，才能通過另外兩塊盤的 儲存校驗資料塊，進行資料恢復，如果壞了兩塊盤則不能進行資料恢復
raid10
先對兩塊盤做raid1，再做raid0
raid1保證資料安全性，raid0保證資料擴充套件性；
侷限，做raid1的兩塊盤同時壞了，則也不能保證資料安全性；
raid如何保證資料安全
bbu(backup battery unit)
保證在電池有電的情況下，即使伺服器發生掉電或者宕機，也能夠將快取中的資料寫入到磁碟，從而保證資料的安全
注意事項
mysql有哪些注意事項
mysql的部署安裝
mysql的監控
mysql引數調優
部署mysql的要求
系統調優的依據：監控
實時監控mysql的slow log
實時監控資料伺服器的負載情況
實時監控mysql內部狀態值
網易內部監控的引數：
binlog檔案大小(mb)
bufferpool命中率(%)
cpu利用率(%)
磁碟讀操作延時(ms/op)
磁碟讀取位元組數(kb/s)
磁碟讀取次數(次/秒)
占用磁碟儲存空間(mb)
磁碟寫入操作延時(ms/op)
磁碟寫入位元組數(kb/s)
磁碟寫入次數(次/秒)
磁碟io利用率(%)
占用記憶體量(%)
記憶體使用率(%)
一般事務提交操作(次/秒)
刪除操作(次/秒)
插入操作(次/秒)
查詢操作(次/秒)
更新操作(次/秒)
二階段事務提交操作(次/秒)
通常關注哪些mysql status
com_select/update/delete/insert
看資料庫的請求是否變多
bytes_received/bytes_sent
看 mysql總的吞吐量
buffer pool hit rate
innodb記憶體的命中率決定了效能
threads_connected/threads_created/threads_running
前兩個多的話， 可以判斷 應用是否使用連線池，或者連線池使用是否合理
活躍連線很多，說明資料庫很忙，可能是被人惡意攻擊；
為什麼要調整mysql的引數：
需要根據業務區動態調整這個通用的mysql資料庫，使其變成專用資料庫
有些引數，很可能是老版本做的，可能是為了限流和保護用的，但是隨著機器的效能提高這些引數，顯然是不合適的。
讀優化合理利用索引對mysql查詢效能至關重用
適當的調整mysql引數也能提公升查詢效能
innodb_buffer_pool_size：
快取池大小，innodb自己維護一塊記憶體區域完成新老資料的替換
innodb_thread_concurrency:
innodb內部併發控制引數，設定為0代表不做控制
如果併發請求較多，餐宿設定較小，後進來的請求將會排隊
寫優化表結構設計上使用自增字段作為表的主鍵
只對合適的字段加索引，索引太多影響寫入效能
監控伺服器磁碟io情況，如果寫延遲較大則需要擴容
選擇正確的mysql版本，合理設定引數
哪些引數有助於提高寫入效能
innodb_flush_log_at_trx_commit&&sync_binlog
控制redo log 重新整理
控制二進位制日誌的重新整理
innodb log file size
innodb_io_capacity
innodb insert buffer
innodb_flush_log_at_trx_commit：0,1,2
n = 0(高效，但不安全--無論伺服器宕機或者mysql宕機都會丟資料)
每隔一秒，把事務日誌快取區的資料寫到日誌檔案中，以及把日誌檔案的資料重新整理到磁碟上
n = 1 (低效，非常安全--都不會丟資料)
每個事務提交時候，把事務日誌從快取區寫到日誌檔案中，並且，重新整理日誌檔案的資料到磁碟上，優化使用此模式保證資料安全性
n = 2(高效，但不安全--伺服器死機會丟資料)
每個事務提交的時候，把事務日誌資料從快取區寫到日誌檔案中，每隔一秒，重新整理一次日誌檔案，但不一定重新整理到磁碟上，而是取決於作業系統的排程；
sync_binlog
控制每次寫入binlog，是否都需要進行一次持久化
如何保證事務安全
innodb_flush_log_at_trx_commit&&sync_binlog 都設為1
事務要和binlog保證一致性---才不會導致主從不一致
事務提交過程
序列有哪些問題
sas盤每秒只能有150--200個fsync
換算到資料每秒只能執行50--60個事務
社群和官方的改進
redo log 的作用
在資料庫 崩潰後的資料恢復；
redo log的問題
如果寫入頻繁導致redo log裡對應的最老的資料髒頁還沒有重新整理到磁碟，此時資料庫將卡住，強制重新整理髒頁到磁碟
mysql預設配置檔案才10m，非常容易寫滿，生成環境中應該提高redo log 的大小
innodb_io_capacity
innodb每次刷多少個髒頁，決定innodb儲存引擎的吞吐能力。
在ssd等高效能儲存介質下，應該提高該引數以提高資料庫的效能。
insert buffer
順序讀寫 vs 隨機讀寫
隨機請求效能遠小於順序請求
將盡可能多的隨機請求合併為順序請求才是提高資料庫效能的關鍵
insert buffer 對二級索引，的增刪改，的操作快取到 insert buffer中，然後將這些隨機請求合併成順序請求；
小結：伺服器配置要合理(核心版本，磁碟排程策略，raid卡快取)
完善的監控系統，提前發現問題
資料庫版本要跟上，不要太新，也不要太老
資料效能優化：
查詢優化：索引優化為主，引數優化為輔
寫入優化：業務優化為主，引數優化為輔
MySQL 日常運維
正規化和反正規化 正規化和反正規化是庫表設計過程中的概念 目前關聯式資料庫有六種正規化，越高的正規化資料庫冗餘越小 正規化化可以較少冗餘，從而減少了在更新資料時一致性方面的開銷 反正規化化由於冗餘的資料，在複雜的查詢場景下，可以避免聯合查詢和子查詢，提高查詢的效率 根據業務場景，選擇合適的正規化等級...
MySQL日常運維操作 持續更新
1 檢視當前連線數 這些引數都是什麼意思呢？threads cached 25 mysql管理的執行緒池中還有多少可以被復用的資源 threads connected 9 開啟的連線數 threads created 55158 表示建立過的執行緒數，如果發現threads created值過大的話...
mysql的日常操作 mysql日常操作命令
1.mysql連線 埠要用大寫p，與密碼p加以區分 mysql h127.0.0.1 p3306 uroot p 2.檢視mysql的資料庫列表 show databases 3.使用某個庫 use 資料庫名 4.檢視表列表 show tables 5.檢視資料庫的建立sql show create...