前言：
保持空杯精神，使用性能剖析，專注於測量伺服器的時間花費在哪裡，思考1、如何確認伺服器是否達到了性能最佳狀態，2、某條語句為什麼不夠快，診斷被用戶描述為「停頓、堆積、卡死」的某些間歇性疑難故障；
接下來將介紹一些工具、技巧優化整機性能、優化單條語句執行速度，診斷 解決那些很難觀察到的問題，展示如何測量系統並生成剖析報告、如何分析系統的堆棧；
3.1簡介
性能：為完成某件任務所需要的時間度量，in other words 性能即響應時間
吞吐量：單位時間內的查詢數據（性能定義的倒數）
第一步：弄清楚時間都去哪了，在哪消耗了時間
如果通測量沒有找到答案，測量方式錯了或不夠完善，只測量需要優化的活動
不要在錯誤的時間啟動或停止測試，測量的是聚合後的信息而不是目標活動本身；需要定位和優化子任務
原則：無法測量便無法有效地優化
3.1.1通過性能剖析進行優化
性能剖析：測量、分析時間花費在哪裡的主要方法
1、測量任務所花費的時間；2、對結果統計、排序（重要前排）
可將相似任務分組匯總，通過性能剖析報告獲需要的結果；報告會列出all任務，每行記錄一個任務：
任務名、執行時間、消耗時間、平均執行時間，執行占全部時間的百分比；按照任務的消耗時間降序排序；
性能剖析類型：
基於執行時間的分析：什麼任務的執行時間最長
基於等待的分析：判斷任務在什麼地方唄阻塞的時間最長
3.1.2理解性能剖析
性能剖析中缺失但是重要的信息：
1、值得優化的查詢
占總響應時間比重很小的查詢不值得優化；成本大於收益、停止優化
2、異常情況
沒有顯式要優化的也要優化，如執行次數少但每次都特別慢的任務
3、未知的未知
丟失時間：任務總時間與實際測量到的時間的差，即使沒有發現也要注意這類問題存在的可能性
4、被掩藏的細節
無法顯示all響應時間的分布，更多信息、直方圖、百分比、標準差、偏差指數
5、無法再更高層次的堆棧中進行交互式 分析
3.2對應用程式進行性能剖析：自上而下
性能瓶頸的影響因素：
1、外部資源，調用外部web服務或搜尋引擎
2、應用需要處理大量數據，分析一個超大的xml文件
3、循環中執行昂貴的操作：濫用正則
4、使用低效的算法：暴力搜索算法
建議：新的項目中應考慮包含性能剖析的代碼
3.2.1測量PHP應用程式：空
3.3剖析MySQL查詢
3.3.1剖析伺服器負載
鋪獲MySQL查詢到日誌文件：
1、慢查詢日誌：開銷低、精度高，大的磁碟空間，長期開啟 注意部署日誌輪轉工具，只在收集負載樣本期間開啟即可，5.1後微秒級別；
2、通用日誌，查詢請求到伺服器時進行記錄，不包含響應時間和執行計劃
分析查詢日誌
自頂向下，先生成剖析報告（pt-query-digest），查看特別關注的部分
3.3.2剖析單條查詢
思考為什麼花費這麼長時間、如何去優化
使用SHOW PROFILE:MySQL5.1後
查看： show variables like "%pro%";【源】
默認禁用，開啟：set profiling=1；然後在伺服器執行語句（關閉 set profiling=off;）
語法：
SHOW PROFILE [type [, type] ... ]
[FOR QUERY n]
[LIMIT row_count [OFFSET offset]]
type:
ALL --顯示所有的開銷信息
| BLOCK IO --顯示塊IO相關開銷
| CONTEXT SWITCHES --上下文切換相關開銷
| CPU --顯示CPU相關開銷信息
| IPC --顯示發送和接收相關開銷信息
| MEMORY --顯示內存相關開銷信息
| PAGE FAULTS --顯示頁面錯誤相關開銷信息
| SOURCE --顯示和Source_function，Source_file，Source_line相關的開銷信息
| SWAPS --顯示交換次數相關開銷的信息
實質是這些開銷信息被記錄到information_schema.profiling表
show profiles；查看
show profile for query 2; 獲取指定查詢的開銷（第二條查詢開銷明細）
show profile cpu for query 2 ;查看特定部分的開銷，如下為CPU部分的開銷
show profile block io,cpu for query 2; 同時查看不同資源開銷
使用SHOW STATUS:計數器
全局show global status、基於某個連接會話級別，作用域要注意
計數器顯示活動的頻繁程度，常用：句柄計數器、臨時文件、表計數器
會創建臨時表，通過句柄操作（引用、指針？）訪問此臨時表，影響show status結果中對應的數字
使用慢查詢日誌：【源】【源】
將MySQL中響應時間超過閾值long_query_time的語句記錄到慢查詢日誌中（日誌可以寫入文件或者資料庫表，如果對性能要求高的話，建議寫文件），默認是10s，需要手動開啟
查看：
（1）slow_query_log的值為ON為開啟慢查詢日誌，OFF則為關閉慢查詢日誌。
（2）slow_query_log_file 的值是記錄的慢查詢日誌到文件中（注意：默認名為主機名.log，慢查詢日誌是否寫入指定文件中，需要指定慢查詢的輸出日誌格式為文件，相關命令為：show variables like 『%log_output%』；去查看輸出的格式）。
（3）long_query_time 指定了慢查詢的閾值，即如果執行語句的時間超過該閾值則為慢查詢語句，默認值為10秒。
（4）log_queries_not_using_indexes 如果值設置為ON，則會記錄所有沒有利用索引的查詢（注意：如果只是將log_queries_not_using_indexes設置為ON，而將slow_query_log設置為OFF，此時該設置也不會生效，即該設置生效的前提是slow_query_log的值設置為ON），一般在性能調優的時候會暫時開啟，開啟後使用full index scan的sql也會被記錄到慢查詢日誌。
//上述命令只對當前生效，當MySQL重啟失效，如果要永久生效，需要配置my.cnf
查看輸出格式：文件？表show variables like 『%log_output%』;
開啟通用日誌查詢： set global general_log=on;
關閉通用日誌查詢： set globalgeneral_log=off;
設置通用日誌輸出為表方式： set globallog_output=』TABLE』;
設置通用日誌輸出為文件方式： set globallog_output=』FILE』;
設置通用日誌輸出為表和文件方式：set global log_output=』FILE,TABLE』;
查詢慢查詢語句的個數：show global status like 『%slow%』;
日誌部分內容簡介：
哪條語句導致慢查詢（sql_text），該慢查詢語句的查詢時間（query_time），鎖表時間（Lock_time），以及掃描過的行數（rows_examined）等信息。
利用自帶的慢查詢日誌分析工具：mysqldumpslow
perl mysqldumpslow –s c –t 10 slow-query.log
-s 表示按何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘；-t 表示top的意思，後面跟著的數據表示返回前面多少條；-g 後面可以寫正則表達式匹配，大小寫不敏感。
使用Performance Schema:【源】【源】
監視MySQL伺服器，收集性能參數，且表的存儲引擎PERFORMANCE_SCHEMA，低耗能
本地伺服器，表是內存表，表內容在伺服器啟動時重新填充，關閉時丟棄，更改不會被複製或寫入二進位日誌
特性：
性能方案配置可被動態的執行SQL修改，立即影響到數據收集
監控服務事件：事件是服務做並被感知到的任何事，時間信息可被收集
資料庫性能方案，提供對運行時資料庫服務進行內部檢查的方式，關注性能數據
特定於一個資料庫服務，資料庫表關聯到數據服務，修改不會被備份也不寫進二進位日誌
存儲引擎用「感知點」收集事件數據，且存儲在performance_schema資料庫，可通過select語句進行查詢
補充：資料庫初始安裝有三個基本庫
mysql
包含權限配置，事件，存儲引擎狀態，主從信息，日誌，時區信息，用戶權限配置等
information_schema
對資料庫元數據的抽象分析，由此提供了SQL語句方式來查詢資料庫運行時狀態，每次對information_schema的查詢都產生對metadata的互斥訪問，影響其他資料庫的訪問性能。
performance_schema
內存型資料庫，使用performance_schema 存儲引擎，通過事件機制將mysql服務的運行時狀態採集並存儲在performace_schema資料庫。注意，兩個單詞之間用下劃線連接時，表示performance_schema是一個資料庫；用空格分開時，表示一個資料庫性能方案，也表示一個存儲引擎。
相關文章：
【MySQL資料庫】第三章解讀：伺服器性能剖析 （下）
【MySQL資料庫】第二章解讀：MySQL基準測試
以上就是【MySQL資料庫】第三章解讀：伺服器性能剖析（上）的詳細內容，更多請關注其它相關文章！
更多技巧請《轉發 + 關注》哦！