MySQL 高效能優化實戰全解!
1.1 前言
在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已。更多關於MySQL查詢相關參照:http://www.cnblogs.com/clsn/p/8038964.html#_label6 系列文章。
圖 – MySQL查詢過程
1.2 優化的哲學
優化有風險,涉足需謹慎
1.2.1 優化可能帶來的問題
優化不總是對一個單純的環境進行,還很可能是一個複雜的已投產的系統。
優化手段本來就有很大的風險,只不過你沒能力意識到和預見到!
任何的技術可以解決一個問題,但必然存在帶來一個問題的風險!
對於優化來說解決問題而帶來的問題,控制在可接受的範圍內才是有成果。
保持現狀或出現更差的情況都是失敗!
1.2.2 優化的需求
穩定性和業務可持續性,通常比效能更重要!
優化不可避免涉及到變更,變更就有風險!
優化使效能變好,維持和變差是等概率事件!
切記優化,應該是各部門協同,共同參與的工作,任何單一部門都不能對資料庫進行優化!
所以優化工作,是由業務需要驅使的!!!
1.2.3 優化由誰參與
在進行資料庫優化時,應由資料庫管理員、業務部門代表、應用程式架構師、應用程式設計人員、應用程式開發人員、硬體及系統管理員、儲存管理員等,業務相關人員共同參與。
1.3 優化思路
1.3.1 優化什麼
在資料庫優化上有兩個主要方面:即安全與效能。
安全 —> 資料可持續性
效能 —> 資料的高效能訪問
1.3.2 優化的範圍有哪些
儲存、主機和作業系統方面:
主機架構穩定性
I/O規劃及配置
Swap交換分割槽
OS核心引數和網路問題
應用程式方面:
應用程式穩定性
SQL語句效能
序列訪問資源
效能欠佳會話管理
這個應用適不適合用MySQL
資料庫優化方面:
記憶體
資料庫結構(物理&邏輯)
例項配置
說明:不管是在,設計系統,定位問題還是優化,都可以按照這個順序執行。
1.3.3 優化維度
資料庫優化維度有四個:
硬體、系統配置、資料庫表結構、SQL及索引
優化選擇
優化成本:硬體>系統配置>資料庫表結構>SQL及索引
優化效果:硬體<系統配置<資料庫表結構<sql及索引< p="">
1.4 優化工具有啥?
1.4.1 資料庫層面
檢查問題常用工具
mysql msyqladmin mysql客戶端,可進行管理操作 mysqlshow 功能強大的檢視shell命令 show [SESSION | GLOBAL] variables 檢視資料庫引數資訊 SHOW [SESSION | GLOBAL] STATUS 檢視資料庫的狀態資訊 information_schema 獲取元資料的方法 SHOW ENGINE INNODB STATUS Innodb引擎的所有狀態 SHOW PROCESSLIST 檢視當前所有連線session狀態 explain 獲取查詢語句的執行計劃 show index 查看錶的索引資訊 slow-log 記錄慢查詢語句 mysqldumpslow 分析slowlog檔案的
不常用但好用的工具
zabbix 監控主機、系統、資料庫(部署zabbix監控平臺) pt-query-digest 分析慢日誌 mysqlslap 分析慢日誌 sysbench 壓力測試工具 mysql profiling 統計資料庫整體狀態工具 Performance Schema mysql效能狀態統計的資料 workbench 管理、備份、監控、分析、優化工具(比較費資源)
1.4.2 資料庫層面問題解決思路
一般應急調優的思路:
針對突然的業務辦理卡頓,無法進行正常的業務處理!需要立馬解決的場景!
1、show processlist
2、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;
3、通過執行計劃判斷,索引問題(有沒有、合不合理)或者語句本身問題
4、show status like ‘%lock%’; # 查詢鎖狀態
kill SESSION_ID; # 殺掉有問題的session
常規調優思路:
針對業務週期性的卡頓,例如在每天10-11點業務特別慢,但是還能夠使用,過了這段時間就好了。
1、檢視slowlog,分析slowlog,分析出查詢慢的語句。
2、按照一定優先順序,進行一個一個的排查所有慢語句。
3、分析top sql,進行explain除錯,檢視語句執行時間。
4、調整索引或語句本身。
1.4.3 系統層面
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.4.4 系統層面問題解決辦法
你認為到底負載高好,還是低好呢?
在實際的生產中,一般認為 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存在問題
1.5 基礎優化
1.5.1 優化思路
定位問題點吮吸
硬體 –> 系統 –> 應用 –> 資料庫 –> 架構(高可用、讀寫分離、分庫分表)
處理方向
明確優化目標、效能和安全的折中、防患未然
1.5.2 硬體優化
主機方面:
根據資料庫型別,主機CPU選擇、記憶體容量選擇、磁碟選擇
平衡記憶體和磁碟資源
隨機的I/O和順序的I/O
主機 RAID卡的BBU(Battery Backup Unit)關閉
cpu的選擇:
cpu的兩個關鍵因素:核數、主頻
根據不同的業務型別進行選擇:
cpu密集型:計算比較多,OLTP 主頻很高的cpu、核數還要多
IO密集型:查詢比較,OLAP 核數要多,主頻不一定高的
記憶體的選擇:
OLAP型別資料庫,需要更多記憶體,和資料獲取量級有關。
OLTP型別資料一般記憶體是cpu核心數量的2倍到4倍,沒有最佳實踐。
儲存方面:
根據儲存資料種類的不同,選擇不同的儲存裝置
配置合理的RAID級別(raid5、raid10、熱備盤)
對與作業系統來講,不需要太特殊的選擇,最好做好冗餘(raid1)(ssd、sas 、sata)
raid卡:主機raid卡選擇:
實現作業系統磁碟的冗餘(raid1)
平衡記憶體和磁碟資源
隨機的I/O和順序的I/O
主機 RAID卡的BBU(Battery Backup Unit)要關閉。
網路裝置方面:
使用流量支援更高的網路裝置(交換機、路由器、網線、網絡卡、HBA卡)
注意:以上這些規劃應該在初始設計系統時就應該考慮好。
1.5.3 伺服器硬體優化
1、物理狀態燈:
2、自帶管理裝置:遠端控制卡(FENCE裝置:ipmi ilo idarc),開關機、硬體監控。
3、第三方的監控軟體、裝置(snmp、agent)對物理設施進行監控
4、儲存裝置:自帶的監控平臺。EMC2(hp收購了), 日立(hds),IBM低端OEM hds,高階儲存是自己技術,華為儲存
1.5.4 系統優化
Cpu:
基本不需要調整,在硬體選擇方面下功夫即可。
記憶體:
基本不需要調整,在硬體選擇方面下功夫即可。
SWAP:
MySQL儘量避免使用swap。
阿里雲的伺服器中預設swap為0
IO :
raid、no lvm、 ext4或xfs、ssd、IO排程策略
Swap調整(不使用swap分割槽)
/proc/sys/vm/swappiness的內容改成0(臨時),/etc/sysctl.conf上新增vm.swappiness=0(永久)
這個引數決定了Linux是傾向於使用swap,還是傾向於釋放檔案系統cache。在記憶體緊張的情況下,數值越低越傾向於釋放檔案系統cache。
當然,這個引數只能減少使用swap的概率,並不能避免Linux使用swap。
修改MySQL的配置引數innodb_flush_method,開啟O_DIRECT模式。
這種情況下,InnoDB的buffer pool會直接繞過檔案系統cache來訪問磁碟,但是redo log依舊會使用檔案系統cache。
值得注意的是,Redo log是覆寫模式的,即使使用了檔案系統的cache,也不會佔用太多
IO排程策略
#echo deadline>/sys/block/sda/queue/scheduler 臨時修改為deadline
永久修改
vi /boot/grub/grub.conf 更改到如下內容: kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet
1.5.5 系統引數調整
Linux系統核心引數優化
vim /etc/sysctl.conf net.ipv4.ip_local_port_range = 1024 65535 # 使用者埠範圍 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_fin_timeout = 30 fs.file-max=65535 # 系統最大檔案控制代碼,控制的是能開啟檔案最大數量
使用者限制引數(mysql可以不設定以下配置)
vim /etc/security/limits.conf * soft nproc 65535 * hard nproc 65535 * soft nofile 65535 * hard nofile 65535
1.5.6 應用優化
業務應用和資料庫應用獨立,
防火牆:iptables、selinux等其他無用服務(關閉):
chkconfig --level 23456 acpid off chkconfig --level 23456 anacron off chkconfig --level 23456 autofs off chkconfig --level 23456 avahi-daemon off chkconfig --level 23456 bluetooth off chkconfig --level 23456 cups off chkconfig --level 23456 firstboot off chkconfig --level 23456 haldaemon off chkconfig --level 23456 hplip off chkconfig --level 23456 ip6tables off chkconfig --level 23456 iptables off chkconfig --level 23456 isdn off chkconfig --level 23456 pcscd off chkconfig --level 23456 sendmail off chkconfig --level 23456 yum-updatesd off
安裝圖形介面的伺服器不要啟動圖形介面 runlevel 3
另外,思考將來我們的業務是否真的需要MySQL,還是使用其他種類的資料庫。用資料庫的最高境界就是不用資料庫。
1.6 資料庫優化
SQL優化方向:
執行計劃、索引、SQL改寫
架構優化方向:
高可用架構、高效能架構、分庫分表
1.6.1 資料庫引數優化
調整:
例項整體(高階優化,擴充套件):
thread_concurrency # 併發執行緒數量個數 sort_buffer_size # 排序快取 read_buffer_size # 順序讀取快取 read_rnd_buffer_size # 隨機讀取快取 key_buffer_size # 索引快取 thread_cache_size # (1G—>8, 2G—>16, 3G—>32, >3G—>64)
連線層(基礎優化)
設定合理的連線客戶和連線方式
相關推薦
MySQL 高效能優化實戰全解!
1.1 前言 在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已。更多關於MySQL查詢相關參照:http://www.cnblogs.com/clsn/p/803
收藏起來,史上最全的 MySQL 高效能優化實戰總結!
摘要: 一、前言 MySQL 對於很多 Linux 從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行 MySQL 的優化之前必須要了解的就是 MySQL 的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL 的優化器能夠按照預想的
史上更全的MySQL高效能優化實戰總結!
一、前言 MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已。 今天給
史上更全的 MySQL 高效能優化實戰總結!
一、前言 MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行
史上最全的MySQL高效能優化實戰總結!
1.1前言 MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想
史上最全的 MySQL 高效能優化實戰總結
一、前言 MySQL 對於很多 Linux 從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行 MySQL 的優化之前必須要了解的就是 MySQL 的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL 的優化器能夠按照預想的
推薦:非常全面的 MySQL 高效能優化實戰總結~
一、前言 MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式執行而已。 今
MySql高效能優化實戰總結(Linux)
MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情 況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優 化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的
知識點:Mysql 索引優化實戰(3)
set ... 存在 over order by select 字節 sele .com 知識點:Mysql 索引原理完全手冊(1) 知識點:Mysql 索引原理完全手冊(2) 知識點:Mysql 索引優化實戰(3) 索引原理知識回顧 索引的性能分析和優化 通過 E
MySQL——索引優化實戰
microsoft hdel 建立 性別 應用 tex 新增 獲取值 blog 上篇文章中介紹了索引的基本內容,這篇文章我們繼續介紹索引優化實戰。在介紹索引優化實戰之前,首先要介紹兩個與索引相關的重要概念,這兩個概念對於索引優化至關重要。 本篇文章用於測試的user表結構:
Mysql效能優化實戰
1、索引設計規範 常見索引列建議: SELECT、UPDATE、DELETE語句的WHERE從句中的列 包含在ORDER BY、GROUP BY、DISTINCT中的欄位,建議聯合索引 多表JOIN的關聯列 索引列的順序: 區分度最高的列放在聯合索引的最左側 儘量把欄位長度
MySQL索引優化實戰
在下列示例中,在name,age,pos上建立複合索引 idx_staffs_nameAgePos 一、全值匹配 這個最高效最直接,如下查詢條件直接是欄位的全值 二、最左字首匹配 如果索引了多列如a、b、c時就需要遵循最左字首法則。指的是查詢從索引的最左前
MySql高效能優化
史上更全的 MySQL 高效能優化實戰總結! 一、前言 MySQL對於很多Linux從業者而言,是一個非常棘手的問題,多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要了解的就是MySQL的查詢過程,很多的查詢優化工作實際上就是遵循一
大資料的三大趨勢和三大困境,你都知道嗎?此文全解!!!
一家公司的數字化改造應該從清晰的趨勢和障礙出發,更好地規劃出一條通往其所尋求業務成果的路線。考慮到這一點,以下是我們關注的三大資料趨勢,以及在數字時代可能出現在企業和成功之間的三大困境。 三大趨勢 1.真實的機器學習 2018年6月2日,由雲豆資料主辦的《大資料時代趨
MySQL 效能優化實戰
鑑於公司專案及業務發展,技術人員從幾人到如今幾十人,後端團隊技術人員日益劇增,可是隨著專案人員的增長,大多研發人員及相關人員經常需要到測試環境使用 MySQL 資料庫,比如移動端、測試、產品,然而他們需要普及 MySQL 知識點及效能優化的知識,其實效能優化的目標是針對後端研
mysql效能優化------explain詳解
1.explain作用 explain語句提供了MySQL如何執行語句的資訊。解釋選擇、刪除、插入、替換和更新語句如何工作。 2.如何使用 explain your command; se
Mysql 效能優化Explain詳解
explain 功能我們在日常使用中,使用慢查詢找到執行時間比較久的查詢,然後使用SHOW STATUS、SHOW PROFILE、和explain做單條語句的分析。使用explain關鍵字可以模擬優化器執行sql查詢語句,從而知道Mysql是如何處理你的sql語句的。分析你的查詢語句或者表結構的效能瓶頸。
MySQL復制異常大掃盲:快速溯源與排查錯誤全解
nts 建庫 statement 版本 end 格式 重做 關閉 容易 MySQL復制異常大掃盲:快速溯源與排查錯誤全解https://mp.weixin.qq.com/s/0Ic8BnUokyOj7m1YOrk1tA作者介紹王松磊,現任職於UCloud,從事MySQL數據
MySQL配置文件mysql.ini參數詳解、MySQL性能優化
說明 select 磁盤 addition sock 硬盤 並發連接 查詢緩存 show my.ini(Linux系統下是my.cnf),當mysql服務器啟動時它會讀取這個文件,設置相關的運行環境參數。 my.ini分為兩塊:Client Section和Serv