如何監控mysql表的變化

本期我們用 MySQL 提供的 DBUG 工具來研究 MySQL 的 SQL 處理流程。

成都創新互聯專注于沅江網站建設服務及定制，我們擁有豐富的企業做網站經驗。 熱誠為您提供沅江營銷型網站建設，沅江網站制作、沅江網頁設計、沅江網站官網定制、成都微信小程序服務，打造沅江網絡公司原創品牌,更為您提供沅江網站排名全網營銷落地服務。

起手先造個實例

這里得稍微改一下實例的啟動文件 start，將 CUSTOM_MYSQLD 改為 mysqld-debug：

重啟一下實例，加上 debug 參數：

我們來做一兩個實驗，說明 DBUG 包的作用：

先設置一個簡單的調試規則，我們設置了兩個調試選項：

d：開啟各個調試點的輸出

O,/tmp/mysqld.trace：將調試結果輸出到指定文件

請點擊輸入圖片描述

然后我們創建了一張表，來看一下調試的輸出結果：

請點擊輸入圖片描述

可以看到 create table 的過程中，MySQL 的一些細節操作，比如分配內存 alloc_root 等

這樣看還不夠直觀，我們增加一些信息：

請點擊輸入圖片描述

來看看效果：

請點擊輸入圖片描述

可以看到輸出變成了調用樹的形式，現在就可以分辨出 alloc_root 分配的內存，是為了解析 SQL 時用的（mysql_parse）

我們再增加一些有用的信息：

請點擊輸入圖片描述

可以看到結果中增加了文件名和行號：

請點擊輸入圖片描述

現在我們可以在輸出中找一下統計表相關的信息：

請點擊輸入圖片描述

可以看到 MySQL 在這里非常機智，直接執行了一個內置的存儲過程來更新統計表。

沿著 que_eval_sql，可以找到其他類似的統計表，比如下面這些：

請點擊輸入圖片描述

請點擊輸入圖片描述

本次實驗中，我們借助了 MySQL 的 DBUG 包，來讓 MySQL 將處理過程暴露出來。MySQL 中類似的技術還有不少，比如 performance_schema，OPTIMIZER_TRACE 等等。

這些技術將 MySQL 的不同方向的信息暴露出來，方便大家理解其中機制。

如何實現MySQL性能監控

命令： show processlist;

如果是root帳號，你能看到所有用戶的當前連接。如果是其它普通帳號，只能看到自己占用的連接。

show processlist;只列出前100條，如果想全列出請使用show full processlist;

mysql show processlist;

命令： show status;

命令：show status like '%下面變量%';

Aborted_clients 由于客戶沒有正確關閉連接已經死掉，已經放棄的連接數量。

如何監控MySQL性能

一，獲取mysql用戶下的進程總數

ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1

二，主機性能狀態

# uptime

[root@ ~]# uptime

13:05:52 up 53 days, 52 min, 1 user, load average: 0.00, 0.00, 0.00

三，CPU使用率

# top

或

# vmstat

四，磁盤IO量

# vmstat 或 # iostat

五，swap進出量[內存]

# free

六，數據庫性能狀態

(1)QPS(每秒Query量)

QPS = Questions(or Queries) / seconds

mysql show /*50000 global */ status like 'Question';

(2)TPS(每秒事務量)

TPS = (Com_commit + Com_rollback) / seconds

mysql show status like 'Com_commit';

mysql show status like 'Com_rollback';

(3)key Buffer 命中率

key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%

key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%

mysql show status like 'Key%';

(4)InnoDB Buffer命中率

innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%

mysql show status like 'innodb_buffer_pool_read%';

(5)Query Cache命中率

Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;

mysql show status like 'Qcache%';

(6)Table Cache狀態量

mysql show status like 'open%';

(7)Thread Cache 命中率

Thread_cache_hits = (1 - Threads_created / connections ) * 100%

mysql show status like 'Thread%';

mysql show status like 'Connections';

(8)鎖定狀態

mysql show status like '%lock%';

(9)復制延時量

mysql show slave status

(10) Tmp Table 狀況(臨時表狀況)

mysql show status like 'Create_tmp%';

(11) Binlog Cache 使用狀況

mysql show status like 'Binlog_cache%';

(12) Innodb_log_waits 量

mysql show status like 'innodb_log_waits';

當然你也可以使用一下開源監控軟件進行監控

一，RRDTool

二，Nagios

三，MRTG

四，Cacti

如何監控MySQL主從同步情況

用 pt-table-checksum 時，會不會影響業務性能？

實驗

實驗開始前，給大家分享一個小經驗：任何性能評估，不要相信別人的評測結果，要在自己的環境上測試，并（大概）知曉原理。

我們先建一對主從：

然后用 mysqlslap跑一個持續的壓力：

開另外一個會話，將 master 上的 general log 打開：

然后通過 pt-table-checksum 進行一次比較：

查看 master 的 general log，由于 mysqlslap 的影響，general log 中有很多內容，我們找到與 pt-table-checksum 相關的線程：

將該線程的操作單獨列出來：

操作比較多，我們一點一點來說明：

這里工具調小了 innodb 鎖等待時間。使得之后的操作，只要在 innodb 上稍微有鎖等待，就會馬上放棄操作，對業務影響很小。

另外工具調小了 wait_timeout 時間，倒是沒有特別的作用。

工具將隔離級別調整為了 RR 級別，事務的維護代價會比 RC 要高，不過后面我們會看到工具使用的每個事務都很小，加上之前提到 innodb 鎖等待時間調到很小，對線上業務產生的成本比較小。

RR 級別是數據對比的基本要求。

工具通過一系列操作，了解表的概況。工具是一個數據塊一個數據塊進行校驗，這里獲取了第一個數據塊的下邊界。

接下來工具獲取了下一個數據塊的下邊界，每個 SQL前都會 EXPLAIN 一下，看一下執行成本，非常小心翼翼。

之后工具獲取了一個數據塊的 checksum，這個數據塊不大，如果跟業務流量有沖突，會馬上出發 innodb 的鎖超時，立刻退讓。

以上是 pt-table-checksum 的一些設計，可以看到這幾處都是精心維護了業務流量不受影響。

工具還設計了其他的一些機制保障業務流量，比如參數 --max-load 和 --pause-file 等，還有精心設計的數據塊劃分方法，索引選擇方法等。大家根據自己的情況配合使用即可達到很好的效果。

總結

本期我們介紹了簡單分析 pt-table-checksum 是否會影響業務流量，坊間會流傳工具的各種參數建議或者不建議使用，算命的情況比較多，大家都可以用簡單的實驗來分析其中機制。

還是那個觀點，性能測試不能相信道聽途說，得通過實驗去分析。

網頁題目：怎么做監控mysql 怎么做監控軟件
URL分享：http://vcdvsql.cn/article16/ddsepgg.html

成都網站建設公司_創新互聯，為您提供網站設計、定制網站、手機網站建設、App設計、域名注冊、外貿網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯