mysql中profile的使用方法教程
profile是什么
當我們要對某一條sql的性能進行分析時,可以使用它。
Profiling是從 mysql5.0.3版本以后才開放的。
啟動profile之后,所有查詢包括錯誤的語句都會記錄在內(nèi)。
關閉會話或者set profiling=0 就關閉了。(如果將profiling_history_size參數(shù)設置為0,同樣具有關閉MySQL的profiling效果。)
此工具可用來查詢SQL執(zhí)行狀態(tài),System lock和Table lock 花多少時間等等,
對定位一條語句的I/O消耗和CPU消耗 非常重要。(SQL 語句執(zhí)行所消耗的最大兩部分資源就是IO和CPU)
--在mysql5.7之后,profile信息將逐漸被廢棄,mysql推薦使用performance schema
mysql官網(wǎng)定義
The SHOW PROFILE and SHOW PROFILES statements display profiling information that indicates resource usage for statements executed during the course of the current session.
簡單的說,當前會話資源的消耗情況。
注意:show profile和show Profiles都是不建議使用的,在mysql后期的版本中可能會被刪除;官網(wǎng)建議使用Performance Schema
怎么使用
profile默認關閉,生產(chǎn)環(huán)境中也建議關閉。
查看當前環(huán)境的profile設置
mysql> show variables like '%profiling%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | have_profiling | YES | | profiling | OFF | | profiling_history_size | 15 | +------------------------+-------+
profiling off表示profile關閉,profiling_history_size 15表示保存最近15條SQL的資源消耗情況。
開啟profile功能,可以使用命令
set global profiling = 1;
然后就可以使用下面命令
show profiles;
查看最近15條SQL的情況;
如果要查看某一條的具體情況,SQL格式為:
SHOW PROFILE [type [, type] ... ]
[FOR QUERY n]
[LIMIT row_count [OFFSET offset]]
type: {
ALL
| BLOCK IO
| CONTEXT SWITCHES
| CPU
| IPC
| MEMORY
| PAGE FAULTS
| SOURCE
| SWAPS
}
官網(wǎng)對type中各個字段的解釋為:
ALL displays all information
BLOCK IO displays counts for block input and output operations
CONTEXT SWITCHES displays counts for voluntary and involuntary context switches
CPU displays user and system CPU usage times
IPC displays counts for messages sent and received
MEMORY is not currently implemented
PAGE FAULTS displays counts for major and minor page faults
SOURCE displays the names of functions from the source code, together with the name and line number of the file in which the function occurs
SWAPS displays swap counts
profiling 對每個會話有效,當會話結(jié)束后,當前的profiling信息就會丟失。
使用案例
mysql> show profiles; +----------+------------+----------------------------+ | Query_ID | Duration | Query | +----------+------------+----------------------------+ | 1 | 0.00060275 | select * from customers | | 2 | 0.00222450 | show tables | | 3 | 0.00567425 | select * from offices | | 4 | 0.00052050 | show tables | | 5 | 0.01123300 | select * from payments | | 6 | 0.00111675 | show tables | | 7 | 0.02049625 | select * from productlines | +----------+------------+----------------------------+
在排查SQL執(zhí)行情況,或者是哪條SQL執(zhí)行非常慢,慢在哪里;profile都是非常的輔助工具。
顯示一條SQL的具體花銷在哪里
mysql> show profile for query 7; +----------------------+----------+ | Status | Duration | +----------------------+----------+ | starting | 0.000043 | | checking permissions | 0.000005 | | Opening tables | 0.014552 | | init | 0.000025 | | System lock | 0.000009 | | optimizing | 0.000004 | | statistics | 0.000011 | | preparing | 0.000010 | | executing | 0.000003 | | Sending data | 0.005653 | | end | 0.000010 | | query end | 0.000009 | | closing tables | 0.000020 | | freeing items | 0.000121 | | cleaning up | 0.000023 | +----------------------+----------+
信息一目了然,這樣我就能對SQL執(zhí)行情況有個大概的了解。
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關文章
MySQL(基于GTID方式)實現(xiàn)主從復制和單主復制詳細教程
在分布式數(shù)據(jù)庫系統(tǒng)中,主從復制是實現(xiàn)高可用性和數(shù)據(jù)冗余的重要手段,基于GTID的復制模式可以提供更強的復制一致性和簡化故障轉(zhuǎn)移過程,本文將詳細介紹如何配置單主復制的GTID模式,以便在MySQL數(shù)據(jù)庫中實現(xiàn)穩(wěn)定可靠的數(shù)據(jù)復制,需要的朋友可以參考下2024-07-07
MySQL+Redis緩存+Gearman共同構(gòu)建數(shù)據(jù)庫緩存的方法
這篇文章主要介紹了MySQL+Redis緩存+Gearman共同構(gòu)建數(shù)據(jù)庫緩存,部署后在MySQL端進行創(chuàng)建一個用戶給與遠程登錄權(quán)限,使得Redis作為緩存可以用來同步數(shù)據(jù)使用,需要的朋友可以參考下2022-10-10
Mysql 出現(xiàn)故障應用直接中斷連接導致數(shù)據(jù)被鎖(生產(chǎn)故障)詳解
這篇文章主要介紹了 Mysql 出現(xiàn)故障應用直接中斷連接導致數(shù)據(jù)被鎖(生產(chǎn)故障)詳解的相關資料,需要的朋友可以參考下2017-01-01
Mysql性能調(diào)優(yōu)之max_allowed_packet使用及說明
這篇文章主要介紹了Mysql性能調(diào)優(yōu)之max_allowed_packet使用及說明,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-11-11
MySQL InnoDB引擎ibdata文件損壞/刪除后使用frm和ibd文件恢復數(shù)據(jù)
mysql的ibdata文件被誤刪、被惡意修改,沒有從庫和備份數(shù)據(jù)的情況下的數(shù)據(jù)恢復,不能保證數(shù)據(jù)庫所有表數(shù)據(jù)的100%恢復,目的是盡可能多的恢復,下面是具體的操作方法2025-03-03

