mysql優化

數據庫層面問題解決思路

通常應急調優的思路：
針對忽然的業務辦理卡頓，沒法進行正常的業務處理！須要立馬解決的場景！

一、show processlist

二、explain select id ,name from stu where name='clsn'; # ALL id name age sex
select id,name from stu where id=2-1 函數 結果集>30;
show index from table;

三、經過執行計劃判斷，索引問題(有沒有、合不合理)或者語句自己問題

四、show status like '%lock%'; # 查詢鎖狀態
kill SESSION_ID; # 殺掉有問題的session

常規調優思路：
針對業務週期性的卡頓，例如在天天 10-11 點業務特別慢，可是還可以使用，過了這段時間就行了。

一、查看 slowlog，分析 slowlog，分析出查詢慢的語句。

二、按照必定優先級，進行一個一個的排查全部慢語句。

三、分析 top sql，進行 explain 調試，查看語句執行時間。

四、調整索引或語句自己。

1. 系統層面

cpu方面：
vmstat、sar top、htop、nmon、mpstat

內存：
free 、ps -aux 、

IO 設備(磁盤、網絡)：
iostat 、 ss 、 netstat 、 iptraf、iftop、lsof、

vmstat 命令說明：
Procs：r 顯示有多少進程正在等待 CPU 時間。b 顯示處於不可中斷的休眠的進程數量。在等待 I/O

Memory：swpd 顯示被交換到磁盤的數據塊的數量。未被使用的數據塊，用戶緩衝數據塊，用於操做系統的數據塊的數量

Swap：操做系統每秒從磁盤上交換到內存和從內存交換到磁盤的數據塊的數量。s1 和 s0 最好是 0

Io：每秒從設備中讀入 b1 的寫入到設備 b0 的數據塊的數量。反映了磁盤 I/O

System：顯示了每秒發生中斷的數量(in)和上下文交換(cs)的數量

Cpu：顯示用於運行用戶代碼，系統代碼，空閒，等待 I/O 的 CPU 時間

iostat 命令說明
實例命令： iostat -dk 1 5
iostat -d -k -x 5 (查看設備使用率(%util)和響應時間(await))

tps：該設備每秒的傳輸次數。「一次傳輸」意思是「一次 I/O 請求」。多個邏輯請求可能會被合併爲「一次 I/O 請求」。

iops ：硬件出廠的時候，廠家定義的一個每秒最大的 IO 次數,"一次傳輸"請求的大小是未知的。

kB_read/s：每秒從設備(drive expressed)讀取的數據量；

KB_wrtn/s：每秒向設備(drive expressed)寫入的數據量；

kB_read：讀取的總數據量；

kB_wrtn：寫入的總數量數據量；這些單位都爲 Kilobytes。

1. 系統層面問題解決辦法

你認爲到底負載高好，仍是低好呢？
在實際的生產中，通常認爲 cpu 只要不超過 90% 都沒什麼問題 。

固然不排除下面這些特殊狀況：
問題一：cpu 負載高，IO 負載低
內存不夠

磁盤性能差

SQL 問題 ------>去數據庫層，進一步排查 sql 問題

IO 出問題了(磁盤到臨界了、raid 設計很差、raid 降級、鎖、在單位時間內 tps 太高)

tps 太高: 大量的小數據 IO、大量的全表掃描

問題二：IO 負載高，cpu 負載低
大量小的 IO 寫操做：

autocommit ，產生大量小 IO

IO/PS 磁盤的一個定值，硬件出廠的時候，廠家定義的一個每秒最大的 IO 次數。

大量大的 IO 寫操做

SQL 問題的概率比較大

問題三：IO 和 cpu 負載都很高
硬件不夠了或 SQL 存在問題

5、基礎優化

1. 優化思路

定位問題點:
硬件 --> 系統 --> 應用 --> 數據庫 --> 架構(高可用、讀寫分離、分庫分表)

處理方向：
明確優化目標、性能和安全的折中、防患未然

1. 硬件優化

主機方面：
根據數據庫類型，主機 CPU 選擇、內存容量選擇、磁盤選擇

平衡內存和磁盤資源

隨機的 I/O 和順序的 I/O

主機 RAID 卡的 BBU(Battery Backup Unit)關閉

cpu 的選擇：
cpu 的兩個關鍵因素：核數、主頻

根據不一樣的業務類型進行選擇：

cpu 密集型：計算比較多，OLTP 主頻很高的 cpu、核數還要多

IO 密集型：查詢比較，OLAP 核數要多，主頻不必定高的

內存的選擇：
OLAP 類型數據庫，須要更多內存，和數據獲取量級有關。

OLTP 類型數據通常內存是 cpu 核心數量的 2 倍到 4 倍，沒有最佳實踐。

存儲方面：
根據存儲數據種類的不一樣，選擇不一樣的存儲設備

配置合理的 RAID 級別(raid 五、raid 十、熱備盤)

對與操做系統來說，不須要太特殊的選擇，最好作好冗餘(raid1)(ssd、sas 、sata)

raid 卡：主機 raid 卡選擇：
實現操做系統磁盤的冗餘(raid1)

平衡內存和磁盤資源

隨機的 I/O 和順序的 I/O

主機 RAID 卡的 BBU(Battery Backup Unit)要關閉

網絡設備方面：
使用流量支持更高的網絡設備(交換機、路由器、網線、網卡、HBA 卡)

注意：以上這些規劃應該在初始設計系統時就應該考慮好。

1. 服務器硬件優化

一、物理狀態燈：

二、自帶管理設備：遠程控制卡(FENCE 設備：ipmi ilo idarc)，開關機、硬件監控。

三、第三方的監控軟件、設備(snmp、agent)對物理設施進行監控

四、存儲設備：自帶的監控平臺。EMC2(hp 收購了)， 日立(hds)，IBM 低端 OEM hds，高端存儲是本身技術，華爲存儲

1. 系統優化

Cpu：
基本不須要調整，在硬件選擇方面下功夫便可。

內存：
基本不須要調整，在硬件選擇方面下功夫便可。

SWAP：
MySQL 儘可能避免使用 swap。阿里雲的服務器中默認 swap 爲 0

IO ：
raid、no lvm、 ext4 或 xfs、ssd、IO 調度策略

Swap 調整(不使用 swap 分區)

這個參數決定了 Linux 是傾向於使用 swap，仍是傾向於釋放文件系統 cache。在內存緊張的狀況下，數值越低越傾向於釋放文件系統 cache。固然，這個參數只能減小使用 swap 的機率，並不能避免 Linux 使用 swap。

修改 MySQL 的配置參數 innodb_flush_method，開啓 O_DIRECT 模式。這種狀況下，InnoDB 的 buffer pool 會直接繞過文件系統 cache 來訪問磁盤，可是redo log 依舊會使用文件系統 cache。值得注意的是，Redo log 是覆寫模式的，即便使用了文件系統的 cache，也不會佔用太多

IO 調度策略：

1. 系統參數調整

Linux 系統內核參數優化：

用戶限制參數(MySQL 能夠不設置如下配置)：

1. 應用優化

業務應用和數據庫應用獨立,防火牆：iptables、selinux 等其餘無用服務(關閉)：

安裝圖形界面的服務器不要啓動圖形界面 runlevel 3,另外，思考未來咱們的業務是否真的須要 MySQL，仍是使用其餘種類的數據庫。用數據庫的最高境界就是不用數據庫。

6、數據庫優化
SQL 優化方向：
執行計劃、索引、SQL 改寫

架構優化方向：
高可用架構、高性能架構、分庫分表

1. 數據庫參數優化

調整：
實例總體(高級優化，擴展)

鏈接層(基礎優化)設置合理的鏈接客戶和鏈接方式