Mysql

1.1.1監(jiān)控指標(biāo)說(shuō)明

主要針對(duì)SQL耗時(shí)、吞吐量(QPS TPS)命中率 鎖等待等指標(biāo)進(jìn)行監(jiān)控。

本來(lái)運(yùn)維工具產(chǎn)品有以下參數(shù)：(global status里面的狀態(tài)量)

TPS/QPS

連接數(shù)

每秒SQL執(zhí)行次數(shù)

全表掃描數(shù)

InnoDB緩沖池命中率

InnoDB緩沖池使用率/臟塊率

InnoDB邏輯讀

排序記錄數(shù)

InnoDB鎖等待次數(shù)

InnoDB臟頁(yè)數(shù)量

InnoDB讀寫(xiě)量

InnoDB buffer pool讀寫(xiě)次數(shù)

InnoDB日志文件寫(xiě)次數(shù)

打開(kāi)文件/表數(shù)量

慢SQL

MyISAM讀寫(xiě)次數(shù)

MyISAM key Buffer 讀/寫(xiě)/利用率(%)

MySQL執(zhí)行語(yǔ)句時(shí)在硬盤(pán)上自動(dòng)創(chuàng)建的臨時(shí)表的數(shù)量

指標(biāo)

解釋

TPS

是Transactions Per Second的縮寫(xiě)，也就是事務(wù)數(shù)/秒。它是軟件測(cè)試結(jié)果的測(cè)量單位。一個(gè)事務(wù)是指一個(gè)客戶(hù)機(jī)向服務(wù)器發(fā)送請(qǐng)求然后服務(wù)器做出反應(yīng)的過(guò)程。客戶(hù)機(jī)在發(fā)送請(qǐng)求時(shí)開(kāi)始計(jì)時(shí)，收到服務(wù)器響應(yīng)后結(jié)束計(jì)時(shí)，以此來(lái)計(jì)算使用的時(shí)間和完成的事務(wù)個(gè)數(shù)。

QPS

是Queries Per Second的縮寫(xiě)，意思是每秒查詢(xún)率，是一臺(tái)服務(wù)器每秒能夠相應(yīng)的查詢(xún)次數(shù)，是對(duì)一個(gè)特定的查詢(xún)服務(wù)器在規(guī)定時(shí)間內(nèi)所處理流量多少的衡量標(biāo)準(zhǔn)。

連接數(shù)

當(dāng)前總連接數(shù)The number of connection attempts (successful or not) to the MySQL server. Connections

每秒SQL執(zhí)行次數(shù)

insert delete update select語(yǔ)句 ROWDML：InnoDB每秒鐘操作數(shù)據(jù)行數(shù)的統(tǒng)計(jì)，根據(jù)操作的不同，分為平均每秒向日志文件的物理寫(xiě)次數(shù)、平均每秒從InnoDB表“刪除/更新/讀取/插入”的行數(shù)。

全表掃描數(shù)

平均每秒全表掃描次數(shù) show global status like “handler_read%”

InnoDB緩沖池命中率

InnoDB buffer pool hit 不低于95%

InnoDB緩沖池使用率/臟塊率

InnoDB緩沖池的讀命中率、利用率以及緩沖池臟塊的百分率(InnoDB緩沖池)

InnoDB物理讀

innodb_buffer_pool_reads: 平均每秒從物理磁盤(pán)讀取頁(yè)的次數(shù)

InnoDB邏輯讀

innodb_buffer_pool_read_requests: 平均每秒從innodb緩沖池的讀次數(shù)

排序記錄數(shù)

Sort_rows

InnoDB鎖等待次數(shù)

Innodb_row_lock_current_waits

InnoDB臟頁(yè)數(shù)量

innodb_buffer_pool_pages_dirty

InnoDB讀寫(xiě)量

InnoDB每秒鐘的讀取和寫(xiě)入次數(shù)。/innodb_data_read innodb_data_written

InnoDB buffer pool讀寫(xiě)次數(shù)

innodb_buffer_pool_read_requests/ innodb_buffer_pool_write_requests

InnoDB日志文件寫(xiě)次數(shù)

InnoDB日志：InnoDB的日志寫(xiě)入情況/ Innodb_log_writes

打開(kāi)文件/表數(shù)量

Innodb_num_open_files/Com_show_open_tables

慢SQL

Slow_queries

MyISAM讀寫(xiě)次數(shù)

MyISAM平均每秒的讀寫(xiě)次數(shù)。 key_read_requests/ key_write_requests

MyISAM key Buffer 讀/寫(xiě)/利用率(%)

MyISAM平均每秒的Key Buffer使用狀況。Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100 —- Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100 — Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100

MySQL執(zhí)行語(yǔ)句時(shí)在硬盤(pán)上自動(dòng)創(chuàng)建的臨時(shí)表的數(shù)量

執(zhí)行語(yǔ)句時(shí)在硬盤(pán)上自動(dòng)創(chuàng)建的臨時(shí)表的數(shù)量(臨時(shí)表)Created_tmp_disk_tables

IOPS

RDS實(shí)例的IOPS(每秒IO請(qǐng)求次數(shù))

系統(tǒng)吞吐量要素：

一個(gè)系統(tǒng)的吞吐量(承壓能力)與request對(duì)CPU的消耗、外部接口、IO等等緊密關(guān)聯(lián)。單個(gè)request 對(duì)CPU消耗越高，外部系統(tǒng)接口、IO速度越慢，系統(tǒng)吞吐能力越低，反之越高。

系統(tǒng)吞吐量幾個(gè)重要參數(shù)：QPS(TPS)、并發(fā)數(shù)、響應(yīng)時(shí)間

QPS(TPS)：(Query Per Second)每秒鐘request/事務(wù) 數(shù)量

并發(fā)數(shù)： 系統(tǒng)同時(shí)處理的request/事務(wù)數(shù)

響應(yīng)時(shí)間： 一般取平均響應(yīng)時(shí)間

(很多人經(jīng)常會(huì)把并發(fā)數(shù)和TPS理解混淆)

理解了上面三個(gè)要素的意義之后，就能推算出它們之間的關(guān)系：

QPS(TPS)= 并發(fā)數(shù)/平均響應(yīng)時(shí)間 或者 并發(fā)數(shù) = QPS*平均響應(yīng)時(shí)間

TPS/QPS區(qū)別及理解：

1、TPS即每秒處理事務(wù)數(shù)，包括：”用戶(hù)請(qǐng)求服務(wù)器”、”服務(wù)器自己的內(nèi)部處理”、”服務(wù)器返回給用戶(hù)”，這三個(gè)過(guò)程，每秒能夠完成N個(gè)這三個(gè)過(guò)程，TPS也就是3；

2、QPS基本類(lèi)似于TPS，但是不同的是，對(duì)于一個(gè)頁(yè)面的一次訪(fǎng)問(wèn)，形成一個(gè)TPS；但一次頁(yè)面請(qǐng)求，可能產(chǎn)生多次對(duì)服務(wù)器的請(qǐng)求，服務(wù)器對(duì)這些請(qǐng)求，就可計(jì)入QPS之中。

3、一般的，評(píng)價(jià)系統(tǒng)性能均以每秒鐘完成的技術(shù)交易的數(shù)量來(lái)衡量。系統(tǒng)整體處理能力取決于處理能力最低模塊的TPS值。

4、QPS對(duì)應(yīng)fetches/sec，即每秒的響應(yīng)請(qǐng)求數(shù)，也即是最大吞吐能力。

MySQL RDS磁盤(pán)占用包括日志文件(binlog文件、錯(cuò)誤日志等)，數(shù)據(jù)文件(數(shù)據(jù)、索引文件)，和一些其他文件(ibdata，logfile_0,臨時(shí)文件等)

造成 MySQL 實(shí)例空間使用率過(guò)高，主要有如下四種原因：

Binlog 文件占用高。

數(shù)據(jù)文件占用高。

臨時(shí)文件占用高。

系統(tǒng)文件占用高。

對(duì)應(yīng)解決方法：

1、定期刪除binlog，假如當(dāng)前dml造成大量的binlog，可以通過(guò)RDS控制臺(tái)即使清理binlog

2、通過(guò)truncate或者drop及時(shí)清除不需要的表

3、終止對(duì)應(yīng)的回話(huà)

4、ibdata中undo占用高可以進(jìn)行undo分離，或者進(jìn)行數(shù)據(jù)轉(zhuǎn)移；增加redo log file的大小和組數(shù)

磁盤(pán)空間、磁盤(pán)空間詳情：

這段時(shí)間的數(shù)據(jù)是一條直線(xiàn)，空間狀態(tài)都很穩(wěn)定，沒(méi)有性能問(wèn)題。

MySQL RDS磁盤(pán)占用包括日志文件(binlog文件、錯(cuò)誤日志等)，數(shù)據(jù)文件(數(shù)據(jù)、索引文件)，和一些其他文件(ibdata，logfile_0,臨時(shí)文件等)

造成 MySQL 實(shí)例空間使用率過(guò)高，主要有如下四種原因：

Binlog 文件占用高。

數(shù)據(jù)文件占用高。

臨時(shí)文件占用高。

系統(tǒng)文件占用高。

對(duì)應(yīng)解決方法：

1、定期刪除binlog，假如當(dāng)前dml造成大量的binlog，可以通過(guò)RDS控制臺(tái)即使清理binlog

2、通過(guò)truncate或者drop及時(shí)清除不需要的表

3、終止對(duì)應(yīng)的回話(huà)

4、ibdata中undo占用高可以進(jìn)行undo分離，或者進(jìn)行數(shù)據(jù)轉(zhuǎn)移；增加redo log file的大小和組數(shù)

MySQL內(nèi)存使用率：

基本上是一條直線(xiàn)，沒(méi)有變化。因?yàn)镸ySQL有innodb_buffer_pool，大約為物理內(nèi)存的50%-80%，內(nèi)存使用率高一些，相對(duì)的性能也會(huì)提高

cpu/mem的使用率：

現(xiàn)在cpu的使用率在30%左右，不算高。內(nèi)存的使用率基本平穩(wěn)在30%左右，正常

CPU的使用率高的原因：

系統(tǒng)執(zhí)行應(yīng)用提交查詢(xún)(包括數(shù)據(jù)修改操作)時(shí)需要大量的邏 輯讀，(邏輯 IO，執(zhí)行查詢(xún)所需訪(fǎng)問(wèn)的表的數(shù)據(jù)行數(shù))，需要消耗大量的 CPU 資源以維護(hù)從存儲(chǔ)系統(tǒng)讀取到內(nèi)存中的數(shù)據(jù)一致性。造成邏輯讀高的原因，很可能是異常SQL，掃描的數(shù)據(jù)行數(shù)過(guò)多導(dǎo)致。

物理內(nèi)存：

直線(xiàn)保持基本無(wú)變化，物理內(nèi)存就是實(shí)際的內(nèi)存條的內(nèi)存大小

連接數(shù)：show processlist

連接數(shù)是指用戶(hù)能夠創(chuàng)建多少個(gè)連接，也就是MySQL show processlist命令輸出結(jié)果中運(yùn)行著的線(xiàn)程個(gè)數(shù)。

當(dāng)前總連接數(shù)： show processlist結(jié)果中的總線(xiàn)程個(gè)數(shù)

當(dāng)前活躍連接數(shù)：show processlist結(jié)果中的活躍線(xiàn)程數(shù)(Command列狀態(tài)為sleep的不計(jì)入在內(nèi))

當(dāng)前連接數(shù)在1500左右，后來(lái)增高至6000左右。但是活躍連接數(shù)一直在個(gè)位數(shù)，說(shuō)明現(xiàn)在的空閑連接數(shù)過(guò)多。總連接數(shù)超過(guò)參考值2000。出現(xiàn)嚴(yán)重問(wèn)題。

數(shù)據(jù)庫(kù)的連接一般是使用長(zhǎng)連接，可能是應(yīng)用側(cè)的連接池初始連接數(shù)設(shè)置過(guò)高，應(yīng)用啟動(dòng)后建立多個(gè)到RDS的空閑連接

解決方法：

1、長(zhǎng)連接建議啟用連接池的復(fù)用連接功能。

2、對(duì)于交互式連接和非交互式連接，建議修改相應(yīng)的wait_timeout和interactive_timeout參數(shù)。(空閑時(shí)間超過(guò)指定的時(shí)間后，RDS的連接會(huì)主動(dòng)關(guān)閉)。通過(guò)DT，RDS控制臺(tái)，性能優(yōu)化，參數(shù)設(shè)置中修改。

3、kill當(dāng)前的空閑會(huì)話(huà)。

網(wǎng)絡(luò)流量：

Bytes_received/s：平均每秒的輸入流量，單位byte/s

Bytes_sent/s：平均每秒的輸出流量，單位byte/s

IOPS：

每秒讀寫(xiě)的次數(shù)。現(xiàn)在是比較小的。在0-0.2之間。

如果IOPS比較高的話(huà)，有可能是以下原因：

1、實(shí)例內(nèi)存滿(mǎn)足不了緩存數(shù)據(jù)或排序等需要，導(dǎo)致產(chǎn)生大量的物理 IO。

2、查詢(xún)執(zhí)行效率低，掃描過(guò)多數(shù)據(jù)行。

解決方法：

1、查詢(xún)是否有慢SQL，優(yōu)化慢SQL，可以參考杜康的實(shí)例卡慢診斷的優(yōu)化建議，或者登錄DMS，通過(guò)診斷報(bào)告、優(yōu)化來(lái)進(jìn)行SQL優(yōu)化

2、終止查詢(xún)語(yǔ)句

3、通過(guò)show processlist，或者DMS控制臺(tái)、杜康等來(lái)kill查詢(xún)回話(huà)id

QPS/TPS：

TPS= Com_insert/s + Com_update/s + Com_delete/s

QPS=Com_select/s + Com_insert/s + Com_update/s + Com_delete/s

官方文檔入口com

QPS比較高，在90000左右，最高到達(dá)110000 。每秒的事務(wù)數(shù)在10000以上。正常，業(yè)務(wù)量比較高

原因分析：

QPS比較高，每秒SQL的語(yǔ)句執(zhí)行次數(shù)高，業(yè)務(wù)量上來(lái)，處于業(yè)務(wù)的高峰期，用戶(hù)連接數(shù)增加，訪(fǎng)問(wèn)量增加。

如果QPS比較高，邏輯讀不高，慢SQL也不是系統(tǒng)的瓶頸，QPS和cpu使用率的變化曲線(xiàn)吻合，這時(shí)候優(yōu)化的余地就不高了，可以從實(shí)例規(guī)格、應(yīng)用架構(gòu)方面進(jìn)行考慮。

如果QPS不高，查詢(xún)執(zhí)行效率低、執(zhí)行時(shí)需要掃描大量表中數(shù)據(jù)、優(yōu)化余地大，并且出現(xiàn)慢查詢(xún)問(wèn)題，QPS和CPU的變化曲線(xiàn)不吻合

如果QPS比較高，并且邏輯讀也比較高，CPU的使用率增加，這時(shí)候可以?xún)?yōu)化優(yōu)化相應(yīng)的慢SQL，添加主實(shí)例的只讀實(shí)例來(lái)緩解壓力。

COMDML：

Com_select/s：平均每秒select語(yǔ)句執(zhí)行次數(shù)

Com_insert/s：平均每秒insert語(yǔ)句執(zhí)行次數(shù)

Com_update/s：平均每秒update語(yǔ)句執(zhí)行次數(shù)

Com_delete/s：平均每秒delete語(yǔ)句執(zhí)行次數(shù)

ROWDML：

innodb_rows_deleted: 平均每秒從innodb表刪除的行數(shù)

innodb_rows_inserted: 平均每秒從innodb表插入的行數(shù)

innodb_rows_read: 平均每秒從innodb表讀取的行數(shù)

innodb_rows_updated: 平均每秒從innodb表更新的行數(shù)

Innodb緩沖池：

緩沖池(innodb buffer pool)簡(jiǎn)單來(lái)說(shuō)就是一塊內(nèi)存區(qū)域。緩沖池中緩存的數(shù)據(jù)頁(yè)類(lèi)型有：索引頁(yè)、數(shù)據(jù)頁(yè)、undo頁(yè)、插入緩沖、自適應(yīng)哈希索引、InnoDB存儲(chǔ)的鎖信息、數(shù)據(jù)字典信息等。不能簡(jiǎn)單認(rèn)為，緩沖池只是緩存索引頁(yè)和數(shù)據(jù)頁(yè)，它們只是占緩沖池很大的一部分而已。

在數(shù)據(jù)庫(kù)中進(jìn)行讀取頁(yè)的操作，首先將從磁盤(pán)讀到的頁(yè)存放在緩沖池中，下一次再讀相同的頁(yè)時(shí)，首先判斷該頁(yè)是否在緩沖池中。若在，稱(chēng)該頁(yè)在緩沖池中被命中，直接讀取該頁(yè)。否則，讀取磁盤(pán)中的頁(yè)。

innodb_buffer_pool_reads: 平均每秒從物理磁盤(pán)讀取頁(yè)的次數(shù)

innodb_buffer_pool_read_requests: 平均每秒從innodb緩沖池的讀次數(shù)

innodb_buffer_pool_write_requests: 平均每秒向innodb緩沖池的寫(xiě)次數(shù)

innodb_buffer_pool_pages_dirty: 平均每秒innodb緩存池中臟頁(yè)的數(shù)目

innodb_buffer_pool_pages_flushed: 平均每秒innodb緩存池中刷新頁(yè)請(qǐng)求的數(shù)目

緩沖池的讀命中率

innodb_buffer_read_hit_ratio = ( 1 – innodb_buffer_pool_reads/innodb_buffer_pool_read_requests) * 100

緩沖池的利用率

innodb_buffer_usage = ( 1 – innodb_buffer_pool_pages_free / innodb_buffer_pool_pages_total) * 100

緩沖池的臟塊的百分率

innodb_buffer_pool_pages_dirty / innodb_buffer_pool_pages_total

Innodb讀寫(xiě)量：

平均每秒讀取的數(shù)據(jù)量：innodb_data_read

平均每秒寫(xiě)入的數(shù)據(jù)量：innodb_data_written

Innodb讀寫(xiě)次數(shù)：

平均每秒Innodb從文件中讀取的次數(shù)：innodb_data_reads

平均每秒Innodb從文件中寫(xiě)入的次數(shù)：innodb_data_writes

Innodb日志：

平均每秒向日志文件的物理寫(xiě)次數(shù)：innodb_log_writes

平均每秒日志寫(xiě)請(qǐng)求次數(shù)：innodb_log_write_requests

平均每秒向日志文件完成fsync()寫(xiě)數(shù)量：innodb_os_log_fsyncs

臨時(shí)表：

Created_tmp_disk_tables：MySQL執(zhí)行語(yǔ)句時(shí)在磁盤(pán)上自動(dòng)創(chuàng)建的臨時(shí)表的數(shù)量

在某些情況下，MySQL服務(wù)器會(huì)自動(dòng)創(chuàng)建內(nèi)部臨時(shí)表。用explain查看select語(yǔ)句的執(zhí)行計(jì)劃，如果extra列顯示“using temporary”,即使用了內(nèi)部臨時(shí)表。一般情況下，MySQL會(huì)先創(chuàng)建內(nèi)存臨時(shí)表，內(nèi)存臨時(shí)表超過(guò)配置指定的值后，MySQL會(huì)將內(nèi)存臨時(shí)表導(dǎo)出到磁盤(pán)臨時(shí)表。

使用臨時(shí)表一般都意味著性能比較低，特別是使用磁盤(pán)臨時(shí)表，性能更慢，因此我們?cè)趯?shí)際應(yīng)用中應(yīng)該盡量避免臨時(shí)表的使用。常見(jiàn)的方法有：

1)創(chuàng)建索引：在ORDER BY或者GROUP BY的列上創(chuàng)建索引；

2)分拆很長(zhǎng)的列：一般情況下，TEXT、BLOB，大于512字節(jié)的字符串，基本上都是為了顯示信息，而不會(huì)用于查詢(xún)條件， 因此表設(shè)計(jì)的時(shí)候，應(yīng)該將這些列獨(dú)立到另外一張表。

如果表的設(shè)計(jì)已經(jīng)確定，修改比較困難，那么也可以通過(guò)優(yōu)化SQL語(yǔ)句來(lái)減少臨時(shí)表的大小，以提升SQL執(zhí)行效率。

MyISAM Key Buffer：

為了最小化磁盤(pán)I/O，MyISAM將最頻繁訪(fǎng)問(wèn)的索引塊(Index block)都放在內(nèi)存中，這樣的內(nèi)存緩沖區(qū)我們稱(chēng)之為Key Cache，它的大小可以通過(guò)參數(shù)key_buffer_size來(lái)控制。在MyISAM的索引文件中，連續(xù)的單元組成一個(gè)Block，Index block的大小等于該BTree索引節(jié)點(diǎn)的大小。Key Cache就是以Block為單位的。

當(dāng)MySQL請(qǐng)求(讀或?qū)?MyISAM索引文件中某個(gè)Index Block時(shí)，首先會(huì)看Key Cache隊(duì)列中是否已經(jīng)緩存了對(duì)應(yīng)block。

如果有，就直接在Key Cache隊(duì)列中進(jìn)行讀寫(xiě)了，不再需要請(qǐng)求磁盤(pán)。如果是寫(xiě)請(qǐng)求，那么Key Cache中的對(duì)應(yīng)Block就會(huì)被標(biāo)記為Dirty(和磁盤(pán)不一致)。在MyISAM在Key Cache成功請(qǐng)求(讀寫(xiě))某個(gè)Block后，會(huì)將該Block放到Key Cache隊(duì)列的頭部。

如果Key Cache中沒(méi)有待請(qǐng)求(讀或?qū)?的Block，MyISAM會(huì)向磁盤(pán)請(qǐng)求對(duì)應(yīng)的Block，并將其放到Key Cache的隊(duì)列頭部。隊(duì)列如果滿(mǎn)了，會(huì)將隊(duì)列尾部的Block刪除，該Block如果是Dirty的，會(huì)將其Flush到磁盤(pán)上。我們看到MyISAM維護(hù)了一個(gè)LRU(Least Recently Used)的Key Cache隊(duì)列。隊(duì)列中的Dirty Block會(huì)在Block被踢出隊(duì)列時(shí)Flush到磁盤(pán)上。

MyISAM平均每秒key buffer利用率

Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100

MyISAM平均每秒key buffer讀命中率

Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100

MyISAM平均每秒key buffer寫(xiě)命中率

Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100

MyISAM讀寫(xiě)次數(shù)：

key_read_requests: MyISAM平均每秒鐘從緩沖池中的讀取次數(shù)

Key_write_requests: MyISAM平均每秒鐘從緩沖池中的寫(xiě)入次數(shù)

key_reads : MyISAM平均每秒鐘從硬盤(pán)上讀取的次數(shù)

key_writes : MyISAM平均每秒鐘從硬盤(pán)上寫(xiě)入的次數(shù)

線(xiàn)程狀態(tài)：

線(xiàn)程數(shù)跟連接數(shù)是對(duì)應(yīng)的。此時(shí)也是連接的總線(xiàn)程數(shù)遠(yuǎn)大于活躍的線(xiàn)程數(shù)。

備庫(kù)延遲：

目前主備延遲(slave-lag)為0.

主備延遲產(chǎn)生的原因：

1 主庫(kù)產(chǎn)生非常大的binlog

a) 主庫(kù)上執(zhí)行大量的dml語(yǔ)句

b) 主庫(kù)上執(zhí)行大事務(wù)

c) 主庫(kù)上沒(méi)有主鍵的全表掃描

2 主庫(kù)上執(zhí)行ddl語(yǔ)句，時(shí)間過(guò)長(zhǎng)

3 備庫(kù)上對(duì)myisam表長(zhǎng)時(shí)間查詢(xún)，阻塞主庫(kù)的binlog同步語(yǔ)句

4 備庫(kù)實(shí)例的規(guī)格配置低，磁盤(pán)IO比較低

查看方法:

1 首先查看備庫(kù)的IOPS是否存在瓶頸

2 備庫(kù)show processlist查看是否存在大事務(wù)

3 主庫(kù)的寫(xiě)入壓力是否過(guò)高，dml語(yǔ)句是否過(guò)多

4 只讀節(jié)點(diǎn)執(zhí)行 show slave status \G，判斷是否有 Waiting for table metadata lock；同時(shí)在主庫(kù)排查下是否有DDL 操作

5 只讀節(jié)點(diǎn)執(zhí)行 show slave status \G，判斷是否有 Waiting for table level lock; 同時(shí)通過(guò) show full processlist; 同時(shí)在主庫(kù)檢查下是否有長(zhǎng)時(shí)間對(duì) MyISAM 引擎表的查詢(xún)

慢SQL：

慢SQL數(shù)量的變化曲線(xiàn)跟CPU的使用率的變化曲線(xiàn)吻合，在CPU使用率高的時(shí)候，慢SQL也跟著增加。可以通過(guò)杜康對(duì)產(chǎn)生的慢SQL進(jìn)行優(yōu)化。

全表掃描次數(shù)：

handeler_read%

隨著業(yè)務(wù)量的增加，全表掃描的次數(shù)也隨之增加。Sql要盡量避免全表掃描

主實(shí)例問(wèn)題與建議：

QPS升高，業(yè)務(wù)量高的情況下，產(chǎn)生一些慢查詢(xún)SQL，并且空閑連接數(shù)太多

連接數(shù)：連接數(shù)嚴(yán)重超過(guò)參考值，并且有過(guò)多的空閑線(xiàn)程。首先檢查應(yīng)用是否使用連接池，如果使用連接池，檢查連接池的配置是否合理

優(yōu)化慢SQL

root@itpux 12:14: [(none)]> show global status like "%innodb%read%"\G

*************************** 1. row ***************************

Variable_name: Innodb_buffer_pool_read_ahead_rnd

Value: 0

*************************** 2. row ***************************

Variable_name: Innodb_buffer_pool_read_ahead

Value: 0

*************************** 3. row ***************************

Variable_name: Innodb_buffer_pool_read_ahead_evicted

Value: 0

*************************** 4. row ***************************

Variable_name: Innodb_buffer_pool_read_requests

Value: 1356

*************************** 5. row ***************************

Variable_name: Innodb_buffer_pool_reads

Value: 240

*************************** 6. row ***************************

Variable_name: Innodb_data_pending_reads

Value: 0

*************************** 7. row ***************************

Variable_name: Innodb_data_read

Value: 4002304

*************************** 8. row ***************************

Variable_name: Innodb_data_reads

Value: 271

*************************** 9. row ***************************

Variable_name: Innodb_pages_read

Value: 239

*************************** 10. row ***************************

Variable_name: Innodb_rows_read

Value: 8

10 rows in set (0.00 sec)

參數(shù)

說(shuō)明

Innodb_buffer_pool_read_ahead

預(yù)讀次數(shù)

Innodb_buffer_pool_read_ahead_evicted

預(yù)讀的頁(yè)，但沒(méi)有被讀取就從緩沖池中被替換的頁(yè)的數(shù)量，一般用來(lái)判斷預(yù)讀的效率

Innodb_buffer_pool_read_requests

從緩存池中讀取頁(yè)的次數(shù)

Innodb_buffer_pool_reads

從物理磁盤(pán)讀取頁(yè)的次數(shù)

Innodb_data_read

總共讀入的字節(jié)數(shù)

Innodb_data_reads

發(fā)起讀取請(qǐng)求的次數(shù)，每次讀取可能需要讀取多個(gè)頁(yè)

緩沖池命中率:

= Innodb_buffer_pool_reads/(Innodb_buffer_pool_reads+Innodb_buffer_pool_read_ahead+Innodb_buffer_pool_read_requests)

參考鏈接

總結(jié)

以上是生活随笔為你收集整理的rds for mysql的监控指标_mysql(RDS)常用性能指标监控的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。