當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

easy connect 获取服务端配置信息失败_如何统计 Mysql 服务器状态信息？

發布時間：2025/3/15 数据库 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 easy connect 获取服务端配置信息失败_如何统计 Mysql 服务器状态信息？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

最近在看《高性能的 Mysql》一書，下面是關于如何學習統計 Mysql 服務器狀態的學習總結，主要是學習使用 SHOW STATUS，SHOW ENGINE INNODB STATUS，SHOW PROCESSLIST，SHOW PROFILE 四個命令。

命令一：SHOW STATUS

show status 命令用于查詢 Mysql 狀態變量相關統計信息
通過 show status like 查看部分變量
這些狀態變量對用戶來說是是只讀的，Mysql 自身在運行過程中會自動更新這些狀態信息
show status 混雜了全局和會話變量，其中很多變量既有全局也有會話級別的
如果會話級別和全局重名，show status 只顯示會話級別的，可以通過 show global status 查看全局狀態
show status 查詢的結果可以在 information_schema.global_status 和 information_schema.session_status 查到

(1)Aborted_* 相關變量

Aborted Connect 表示嘗試連接到 MySQL 服務器失敗的次數，引起這個狀態變量激增的原因如下：

客戶端沒有權限但是嘗試訪問 MySQL 數據庫
客戶端輸入的密碼有誤
A connection packet does not contain the right information(連接發送包數據不正確)，這種情況下一般都是監控系統檢查服務器 3306 端口是否存活報錯導致的
超過連接時間限制，連接超時時間由系統變量 connect_timeout 控制(mysql 默認是 10s)

Aborted Clients 意味著有客戶端成功建立連接，但是由于某些原因斷開連接或者被終止了，這種情況一般發生在網絡不穩定的環境中。主要的可能性有：

客戶端程序在退出之前未調用 mysql_close()正確關閉 MySQL 連接
客戶端休眠的時間超過了系統變量 wait_timeout 和 interactive_timeout 的值，導致連接被 MySQL 進程終止
客戶端程序在數據傳輸過程中突然結束

(2)connection* 相關變量

mysql> show status like '%connections%'; +-----------------------------------+-------+ | Variable_name | Value | +-----------------------------------+-------+ | Connection_errors_max_connections | 0 | | Connections | 197 | | Max_used_connections | 2 | +-----------------------------------+-------+

connections 表示MySQL從啟動至今，成功建立連接的連接數，這個值是不斷累加的
Max_used_connections 表示 MySQL 從啟動至今，同一時刻并發的連接數的最大值。如果這個值大于 max_connections 參數配置則表明系統經常處于高并發的狀態，應該考慮調大最大并發連接數
Connection_errors_max_connections 當 MySQL 的最大并發數大于系統變量 max_connections 的最大并發數，因此而被拒絕的次數，將會記錄在這個變量里。如果 Connection_error_max_connections 值比較大，則說明當前系統并發比較高，要考慮調大 max_connections 的值。

這邊順便了解一下關于連接信息的系統變量配置：

mysql> show variables like '%connect%'; +-----------------------------------------------+-----------------+ | Variable_name | Value | +-----------------------------------------------+-----------------+ | character_set_connection | utf8 | | connect_timeout | 10 | | max_connect_errors | 100 | | max_connections | 151 | | max_user_connections | 0 | +-----------------------------------------------+-----------------+

max_connections：

是指 MySQL 服務實例能夠同時接受的的最大并發連接數。MySQL 實際上支持最大連接數加一的算法，保障當連接數用完的時候，超級管理員依然可以和服務端建立連接，進行管理。

max_user_connections：

每個賬號的最大并發連接數。

max_connect_errors：

當某臺非法主機惡意連接 MySQL 服務端，遭到的錯誤達到設置值后，MySQL 會拒絕來自該主機的所有連接。但執行 flush hosts 后會清零。

connect_timeout

在獲取連接階段(authenticate)起作用，獲取 MySQL 連接是多次握手的結果，除了用戶名和密碼的匹配校驗外，還有 IP->HOST->DNS->IP 驗證，任何一步都可能因為網絡問題導致線程阻塞。為了防止線程浪費在不必要的校驗等待上，超過 connect_timeout 的連接請求將會被拒絕，默認值 10 秒。

(3)Thread_* 相關變量

Thread_cached 在緩存中的線程數，該數字受 thread_cache_size 參數大小的影響
Thread_connected 當前的連接數
Thread_created: 從啟動到現在，創建過的線程數，如果該值很大，建議調大 thread_cache_size 參數
Thred_running：當前活躍的線程數

(4)Com_* 開頭的統計變量

mysql> show global status like 'Com%'; +-----------------------------+-------+ | Variable_name | Value | +-----------------------------+-------+ | Com_change_db | 4444 | | Com_select | 5117790905 | | Com_alter_db | 0 | ..... +-----------------------------+-------+

Com_* 開頭的統計信息主要用于記錄每種類型的 SQL 發起過的次數，例如 Com_delete 和 Com_insert 用于統計 Delete 和 Insert 操作的次數，但是如果一次查詢命中緩存，該數字將不會被記錄。注意的是 show global status like 'Com%' 和 show status like 'Com%' 的區別，后者可能只顯示當前會話的統計值。

(5)Created_tmp* 臨時文件和臨時表統計

(6)查詢緩存的統計

通過變量 query_cache_type 來設置是否開啟緩存，通過變量 query_cache_limit 來設置緩存結果集的上限，如果某次查詢超過該上限制則不進行緩存

(7)Select 查詢類型統計

Select.* 統計特定類型 Select 查詢的計數器，它可以幫我們了解各種查詢計劃

Select_scan：表示查詢時第一張表整表掃描的次數，如果你并不想要第一張表的所有行但是又沒用索引，此時查詢性能很差
Select_range：在第一張表上掃描索引區間的查詢數目
Select_range_check：這個比 Select_full_join 要好一點，和 Select_range 差不多。區別是 MySQL 不能確定它能否使用一個范圍來做關聯查詢。如果可以那么會使用范圍，如果不行仍會使用全表掃描
Select_full_join：和 Select_scan 差不多，區別是 Select_full_join 代表的是第二張及之后的表
Select_full_range_join：和 Select_range_check 類似，不過 MySQL 可以肯定它能夠使用范圍查找。這時 explain 中的類型是 range

(8)Sort.* 類型統計

當 mysql 不能使用一個索引來進行預先排序的時，必須使用文件排序，這就會增加 Sort* 狀態變量的值，

Sort_range：當 Mysql 從文排序結果中讀取已經排序好的行時，如果是 Select_range 增加，那么 Sort_range 也會增加
Sort_scan：當 Mysql 從文排序結果中讀取已經排序好的行時，如果是 Select_scan 增加，那么 Sort_scan 也會增加
Sort_rows：被排序記錄的總數
Sort_merge_passes： Mysql 在排序時首先嘗試在內存中做排序，使用內存的大小由 Sort_buffer_size 決定，如果超過該大小會將排序結果放在臨時文件中，最后進行統一合并，此時會增加 Sort_merge_passes 的值

(9)Table_locks.* 表鎖相關統計

Table_locks_immediate：這個表示有多少鎖當查詢到來時立即被授權
Table_locks_waited：這個表示有多少鎖當查詢到來時需要等待，如果該值較大說明鎖爭用比較嚴重，因為 InnoDb 支持行級鎖，該值一般都很小

命令二：SHOW ENGINE INNODB STATUSG

show engine innodb status 輸出了關于 InnoDB 一些平均值的統計信息，對于數據的采樣計算的時間間隔也不總是相同的，里面提供了大多數你要想要的統計信息。

該命令輸出是一個單獨的字符串，沒有行和列，分為很多小段，所以加 G 參看更為方便，每一段都對應了 InnoDB 存儲引擎不同部分的信息，

(1)頭部信息

-- 表示當前輸出結果是對過去某個時間范圍內 InnoDB 存儲引擎的狀態的統計 Per second averages calculated from the last 60 seconds

(2)BACKGROUND THREAD

InnoDB 存儲引擎的核心操作大部分都集中在 Mater Thread 后臺線程中，該狀態顯示了后臺線程狀態信息，Master Thread 的主要工作：

主循環(loop)主要以每一秒和每十秒的頻率執行刷新日志緩存，合并插入緩存，刷新臟頁緩存，刪除無用 undo 頁等操作
如果當前沒有用戶活動，則進入后臺循環流程(backgroud loop)，主要執行刪除無用的 undo 頁，合并插入緩存
如果沒有什么事情可以做了，便進入了暫停循環(suspend loop)，等待事件循環喚起

----------------- BACKGROUND THREAD ----------------- # srv_active 為每秒的循環次數，srv_idle 為每 10 秒的的循環次數，srv_shutdown 為停止的循環，通常為 0 # 如果每秒循環次數少，每 10 秒次數多，證明當前負載很低；如果每秒循環次數多，每 10 秒次數少，遠大于10：1，證明當前負載很高 srv_master_thread loops: 2818842 srv_active, 0 srv_shutdown, 411 srv_idle # 日志緩沖刷盤次數 srv_master_thread log flush and writes: 2819194

(3)SEMAPHORES(信號量)

主要包含了兩種數據：事件計數器以及可選的當前等待線程列表。首先了解一下 InnoDB 如何兩步獲得鎖過程：

首先線程試圖獲得一個鎖，如果此鎖被它人占用。它就會執行所謂的 spin wait，輪詢查看鎖是否釋放
如果在循環過程中，一直未得到鎖釋放的信息，則其轉入 os wait，即線程進入掛起(suspended)狀態
直到鎖被釋放后，通過信號(singal)喚醒線程

spin wait 的消耗遠小于 os waits，spin wait 利用 cpu 的空閑時間，檢查鎖的狀態，os Wait 從 CPU 內核中換出當前執行線程以供其它線程使用。所以應盡量減少 os waits，可以通過 innodb_sync_spin_loops 參數來平衡 spin wait 和 os wait。

---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 293642477 # 表示 InnoDB 產生了多少次操作系統的等待 OS WAIT ARRAY INFO: signal count 117881542 # 表示進入 OS WAIT 的線程被喚醒次數 RW-shared spins 0, rounds 318628772, OS waits 205885745 # 共享鎖 RW-excl spins 0, rounds 2120303681, OS waits 66818882 # 排他鎖 RW-sx spins 16623848, rounds 479205501, OS waits 15180111 # 共享排他鎖 Spin rounds per wait: 318628772.00 RW-shared, 2120303681.00 RW-excl, 28.83 RW-sx

(4)LATEST FOREIGN KEY ERROR

該錯誤一般不會出現，除非你服務器上外鍵錯誤，比如違反外鍵約束去更新，刪除數據，或者去修改外鍵的類型導致類型不匹配，都會報這個錯， show engine innodb status 在每次有新錯誤時，該信息都會被重寫

(5)LATEST DETECTED DEADLOCK

記錄最近一次死鎖信息，只有產生過死鎖才會有記錄。該信息對于查看到底是什么導致死鎖非常有用

通過下面的信息我們可以知道死鎖的發生時間，死鎖里每個事務的狀態和信息

------------------------ LATEST DETECTED DEADLOCK ------------------------ 190425 18:00:13 *** (1) TRANSACTION: TRANSACTION 231E7C5DF, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1248, 3 row lock(s) MySQL thread id 1346996, OS thread handle 0x7fd968454700, query id 760545285 10.10.x.x app_user updating DELETE FROM db_0.table_0 WHERE ORDER_ID IN ( 456787464 , 456787465 ) *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DF lock_mode X waiting Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** (2) TRANSACTION: TRANSACTION 231E7C5DD, ACTIVE 0 sec starting index read, thread declared inside InnoDB 1 mysql tables in use 1, locked 1 5 lock struct(s), heap size 1248, 4 row lock(s) MySQL thread id 1348165, OS thread handle 0x7fd96669f700, query id 760545283 10.10.x.x app_user updating DELETE FROM db_0.table_0 WHERE ORDER_ID IN ( 456787464 , 456787465 ) *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DD lock_mode X locks rec but not gap Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 5 page no 6064 n bits 824 index `orderId_index` of table `db_0`.`table_0` trx id 231E7C5DD lock_mode X waiting Record lock, heap no 180 PHYSICAL RECORD: n_fields 2; compact format; info bits 32 0: len 8; hex 80000015eb6a1041; asc j A;; 1: len 8; hex 800000002018fce2; asc ;; *** WE ROLL BACK TRANSACTION (1) # 這個表示那個事務被選中成為死鎖的犧牲品

(6)TRANSACTIONS

包含了 InnoDB 事務(transaction)的統計信息。

------------ TRANSACTIONS ------------ # 當前的事務 ID，這是一個系統變量，每創建一個新事務會加 1 Trx id counter 319435931 # Purge done for trx's 這個表示清除舊的 MVCC 行時所用到的事務 ID，和當前事務 ID 相比較，可以知道有多少老版本數據未被清理。 # undo n:o 表示正在使用的 undo 日志編號，如果是 0 的話，表明處于空閑狀態 Purge done for trx's n:o < 319435931 undo n:o < 0 state: running but idle # 這個表示 InnoDB undo 日志文件頁面的個數，如果事務執行了更新并提交，這個數字會增加，當清理進程移除舊版本數據時，該值會減少 History list length 1631

(7)FILE I/O

在 InnoDB 中大量使用了 AIO(Async IO)來處理 IO 請求，IO Thread 主要是負責這些 IO 請求的回調處理，通過調用 fsync() 函數協調內存與磁盤之間的數據。

主要包括以下幾種 IO 線程：

insert buffer thread：插入合并緩存線程
log thread：異步刷新事務日志線程
read thread：讀線程，通過參數 innodb_read_io_threads 控制個數，默認是 4
write thread：寫線程，主要用于刷新臟頁緩存，通過參數 innodb_write_io_threads 控制個數，默認是 4
purge thread：回收已經使用并分配的 undo 頁，從 Master Thread 線程中分離出來，提高 CPU 的利用率。innodb 1.2 版本以后，可以通過參數 innodb_purge_threads 來設置 Purge 線程的個數
page cleaner thread：負責臟頁的刷新，innodb 1.2 版本以后從 Master Thread 線程中分離出來，提高 CPU 的利用率，減輕 Master Thread 的壓力

FILE I/O 顯示了輔助線程的狀態以及性能計數器的狀態

-------- FILE I/O -------- # 各個輔助線程的狀態信息 I/O thread 0 state: waiting for completed aio requests (insert buffer thread) I/O thread 1 state: waiting for completed aio requests (log thread) I/O thread 2 state: waiting for completed aio requests (read thread) I/O thread 3 state: waiting for completed aio requests (read thread) I/O thread 4 state: waiting for completed aio requests (read thread) I/O thread 5 state: waiting for completed aio requests (read thread) I/O thread 6 state: waiting for completed aio requests (write thread) I/O thread 7 state: waiting for completed aio requests (write thread) I/O thread 8 state: waiting for completed aio requests (write thread) I/O thread 9 state: waiting for completed aio requests (write thread) # 下面三行顯示的是每個輔助線程被掛起操作的數目，如果這些 I/O 大部分有掛起的操作，那么負載可能 I/O 受限 Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] , ibuf aio reads:, log i/o's:, sync i/o's: Pending flushes (fsync) log: 0; buffer pool: 0 # 顯示的是讀，寫，fsync 調用執行的次數 230490715 OS file reads, 200072148 OS file writes, 154690982 OS fsyncs # 每個線程每秒的平均值 17.15 reads/s, 16384 avg bytes/read, 23.65 writes/s, 21.08 fsyncs/s

(8)INSERT BUFFER AND ADAPTIVE HASH INDEX

插入緩存：

插入緩存主要用于非聚集索引的插入和更新操作，把多次插入和更新操作放在一個 Insert Buffer 對象里，再以一定的頻率進合并更新，提高性能。

自適應哈希索引

InnoDB 會監控對表上各個索引頁的查詢，如果觀察到通過哈希索引可以帶來性能提升，則自動建立哈希索引，通過參數 innodb_adaptive_hash_index 來禁用或啟動

INSERT BUFFER AND ADAPTIVE HASH INDEX 顯示了插入緩存和自適應哈希索引的使用情況。

------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- # Ibuf 表示已經合并頁的數量，free list len 表示空閑列表長度，seg size 表示 Insert Buffer 的大小，merges 表示合并次數， Ibuf: size 1, free list len 80, seg size 82, 2639224 merges # 分別查看 Insert Buffer, Delete Buffer, Purge Buffer 的次數 merged operations: insert 4178472, delete mark 151972, delete 60065 # 不需要合并的次數 discarded operations: insert 0, delete mark 0, delete 0 # 自適應 hash 索引的大小 Hash table size 276671, node heap has 5 buffer(s) Hash table size 276671, node heap has 21 buffer(s) Hash table size 276671, node heap has 56 buffer(s) Hash table size 276671, node heap has 210 buffer(s) Hash table size 276671, node heap has 8 buffer(s) Hash table size 276671, node heap has 111 buffer(s) Hash table size 276671, node heap has 9 buffer(s) Hash table size 276671, node heap has 33 buffer(s) # 通過 hash 索引查詢每秒個數，無法通過 hash 索引查詢每秒的個數 4798.09 hash searches/s, 600.67 non-hash searches/s

(9)LOG

這部分內容顯示的是關于 InnoDB 重做日志的統計，以下三種情況重做日志都會被刷新到磁盤

Master Thread 會每秒進行刷新
每個事務提交時會刷新
重做日志緩存空間小于 1/2 時會強制刷新

--- LOG --- Log sequence number 197081867058 # 當前日志 LSN 序號 Log flushed up to 197081867058 # 日志刷新到磁盤的 LSN 序號 Pages flushed up to 196985565734 # 已經刷新到磁盤頁的 LSN 序號 Last checkpoint at 196985468367 # 上一次 Checkpoint 的 LSN 序號 # 統計日志的總量及每秒日志的量 0 pending log flushes, 0 pending chkp writes 142876358 log i/o's done, 18.32 log i/o's/second

(10)BUFFER POOL AND MEMORY

這部分信息顯示了關于 InnoDB 緩存池及其如何使用內存的統計，為了提高數據庫的性能，引入緩存池的概念，通過參數 innodb_buffer_pool_size 可以設置緩存池的大小，參數 innodb_buffer_pool_instances 可以設置緩存池的實例個數。緩存池主要用于存儲以下內容：索引頁，數據頁，undo 頁，插入緩存(insert buffer)，自適應哈希索引(adaptive hash index)，鎖信息，數據字典信息等信息。

---------------------- BUFFER POOL AND MEMORY ---------------------- Total large memory allocated 2198863872 # InnoDB 分配的總內存 Dictionary memory allocated 7884277 # InnoDB 數據字典分配的內存數， Buffer pool size 131064 # innodb_buffer_pool 頁的數量 Free buffers 1024 # LRU 列表中空閑頁的數量 Database pages 129587 # LRU 列表中非空閑頁的數量 Old database pages 47815 # LRU 列表中 old 頁的數量，new 和 old 頁的分界通過參數 innodb_old_blocks_pct 設置 Modified db pages 20916 # 臟頁的數量 Pending reads 0 # 掛起讀的數量 Pending writes: LRU 0, flush list 0, single page 0 # 掛起的寫的數量 Pages made young 125019609, not young 11734595709 6.70 youngs/s, 109.36 non-youngs/s # read 是指從磁盤讀到緩存池中，written 是從緩存池寫入磁盤，created 是指在緩存池中分配但沒有從數據文件中讀取的頁 Pages read 230491590, created 15808941, written 53911882 17.15 reads/s, 1.20 creates/s, 4.28 writes/s # 緩存命中率 Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 4 / 1000

(11)ROW OPERATIONS

顯示了 row 操作及其他一些統計信息

-------------- ROW OPERATIONS -------------- # queries，表示 innodb 內核中有多少個線程，隊列中有多少個線程 0 queries inside InnoDB, 0 queries in queue # 表示有多少個讀視圖被打開，一個讀視圖包含從事務開始數據庫內容的 MVCC 快照 0 read views open inside InnoDB # 內核主線程的狀態，大部分情況下處于"sleeping"，主線程主要工作有 making checkpoint, flushing log, flushing buffer poll pages 等 Process ID=51, Main thread ID=140023262725888, state: sleeping # 表示多少行被插入，更新和刪除，讀取及每秒讀取信息，可用于監控 Number of rows inserted 637410366, updated 210696023, deleted 335066, read 311734809045 60.43 inserts/s, 9.95 updates/s, 0.00 deletes/s, 48640.59 reads/s

命令三：SHOW PROCESSLIST

顯示了當前連接到 MYSQL 的連接或者線程的狀態，除了 root 用戶能看到所有正在運行的線程外，其他用戶都只能看到自己正在運行的線程，看不到其它用戶正在運行的線程。除非單獨為這個用戶賦予了 PROCESS 權限。show processlist 的結果其實來自于 information_schema.processlist 表，所以我們通過查詢 information_schema.processlist 表可以獲取對于排查性能問題有用的信息，比如哪個客戶端連接信息最多，哪些線程執行時間最長等信息。

SHOW PROCESSLISTG; *************************** 238. 行 *************************** Id : 666748 User : youdata Host : 10.255.0.2:56058 db : youdata Command : Sleep Time : 127 ACK_WAIT_TIME: 0 State : Info : *************************** 239. 行 *************************** Id : 666761 User : youdata Host : 10.255.0.2:60619 db : NULL Command : Query Time : 0 ACK_WAIT_TIME: 0 State : starting Info : starting 239 行于數據集 (0.51 秒)

下面看一下每個字段的含義：

Id：這個是線程的唯一標志，當遇到問題時可以通過 kill 加上這個 Id 值將這個線程殺掉
User：表示啟動線程的用戶
Host：記錄了發送請求的客戶端的 IP 和端口
DB：執行的數據庫
Command：正在執行的命令，比如 Query，Create DB，Quit，Sleep 等
Time：該線程處于當前狀態的時間
State：線程的狀態,有很多種情況，下面只列舉了部分：

- Checking table: 正在檢查數據表 - Closing tables：正在將表中修改的數據刷新到磁盤中，同時正在關閉已經用完的表 - Locked：被其它查詢鎖住了 - Sending data：正在處理 Select 查詢的記錄同時把數據發動到客戶端 - Sorting for group：正在為 group by 操作做排序 - Updating：正在尋找匹配的記錄來修改他們 ....

Info：一般記錄的是線程執行的語句。默認只顯示前 100 個字符，也就是你看到的語句可能是截斷了的，要看全部信息，需要使用 show full processlist

命令四：SHOW PROFILE

mysql 5.1 版本開始支持 SHOW PROFILE
SHOW PROFILE 可以高精度的記錄每個查詢語句在運行過程中各個操作的執行時間
開啟 SET profiling = ON，默認關閉
SHOW PROFILES 可以列出最近 N 條 SQL 的執行時間，N 默認是 15，可以通過參數 profiling_history_size 進行控制

mysql> show profiles; +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ | Query_ID | Duration | Logical_reads | Physical_reads | Query | +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ | 1 | 0.00019325 | 0 | 0 | select @@version_comment limit 1 | | 2 | 0.00043125 | 0 | 0 | SELECT DATABASE() | | 3 | 0.00058600 | 0 | 0 | show databases | | 4 | 0.00060725 | 0 | 0 | show tables | | 5 | 0.00013125 | 0 | 0 | show global profiles | | 6 | 0.00014375 | 0 | 0 | show global profiles | | 7 | 0.00073550 | 0 | 0 | select * from bigviz_user where email like "%hzzhang%" order by nick desc | | 8 | 0.01025300 | 0 | 0 | select count(*) from new_component | +----------+------------+---------------+----------------+---------------------------------------------------------------------------+ 8 rows in set, 1 warning (0.00 sec)

SHOW PROFILE 可以列出最近一條語句的執行詳細信息。如果指定 FOR QUERY n 子句時，可以列出最近 N 條中某條語句的執行詳細信息, 其中 n 表示上面顯示的 Query_ID

mysql> show for query 7; +----------------------+----------+ | Status | Duration | +----------------------+----------+ | starting | 0.000158 | | checking permissions | 0.000013 | | Opening tables | 0.000028 | 打開表 | init | 0.000073 | | System lock | 0.000018 | 加鎖 | optimizing | 0.000015 | | statistics | 0.000026 | | preparing | 0.000017 | | Sorting result | 0.000010 | 排序 | executing | 0.000005 | | Sending data | 0.000029 | 發送數據 | Creating sort index | 0.000223 | | end | 0.000008 | | query end | 0.000011 | | closing tables | 0.000039 | 關閉表 | freeing items | 0.000039 | | cleaning up | 0.000025 | +----------------------+----------+ 17 rows in set, 1 warning (0.00 sec)

SHOW PROFILE 只對當前會話生效，所以我們一般是在命令行工具里開啟然后執行自己想要分析的SQL，再通過 show profile 查看性能。

總結

以上是生活随笔為你收集整理的easy connect 获取服务端配置信息失败_如何统计 Mysql 服务器状态信息？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： php smarty模板配置,Smart
下一篇： mysql同步数据到另一张表_mysql