當(dāng)前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

MySQL 性能监控 4 大指标

發(fā)布時間：2023/12/19 数据库 27 豆豆

生活随笔收集整理的這篇文章主要介紹了 MySQL 性能监控 4 大指标小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

?

【編者按】本文作者為 John Matson，主要介紹?mysql?性能監(jiān)控應(yīng)該關(guān)注的 4 大指標(biāo)。文章系國內(nèi)?ITOM?管理平臺?OneAPM?編譯呈現(xiàn)。

MySQL 是什么？

MySQL?是現(xiàn)而今最流行的開源關(guān)系型數(shù)據(jù)庫服務(wù)器。由?Oracle?所有，MySQL 提供了可以免費(fèi)下載的社區(qū)版及包含更多特性與支持的商業(yè)版。從 1995 年首發(fā)以來，MySQL 衍生出多款備受矚目的分支，諸如具有相當(dāng)競爭力的 MariaDB 及 Percona。

關(guān)鍵 MySQL 統(tǒng)計指標(biāo)

如果你的數(shù)據(jù)庫運(yùn)行緩慢，或者出于某種原因無法響應(yīng)查詢，技術(shù)棧中每個依賴數(shù)據(jù)庫的組件都會遭受性能問題。為了保證數(shù)據(jù)庫的平穩(wěn)運(yùn)行，你可以主動監(jiān)控以下四個與性能及資源利用率相關(guān)的指標(biāo)：

查詢吞吐量
查詢執(zhí)行性能
連接情況
緩沖池使用情況

MySQL 用戶可以接觸到數(shù)百個數(shù)據(jù)庫指標(biāo)，因此，在本文中，筆者將專注于能幫助我們實時了解數(shù)據(jù)庫健康與性能的關(guān)鍵指標(biāo)。

本文參考了我們在監(jiān)控入門系列文章中介紹的指標(biāo)術(shù)語，后者為指標(biāo)收集與告警提供了基礎(chǔ)框架。

不同版本與技術(shù)的兼容性

本系列文章討論的一些監(jiān)控策略只適用于 MySQL 5.6 與 5.7 版本。這些版本間的差異將在后文中提及。

本文列出的大多數(shù)指標(biāo)與監(jiān)控策略同樣適用于與 MySQL 兼容的技術(shù)，諸如 MariaDB 與 Percona 服務(wù)器，不過帶有一些明顯的差別。例如，MySQL Workbench(工作臺) 中的一些特性（在本系列第二篇中有詳細(xì)介紹）就與當(dāng)下的一些 MariaDB 版本不兼容。

Amazon RDS 用戶應(yīng)該查看我們專門制作的?MySQL 在 RDS?以及與 MySQL 兼容的?Amazon Aurora監(jiān)控手冊。

查詢吞吐量

名稱描述指標(biāo)類型可用性

Questions	已執(zhí)行語句（由客戶端發(fā)出）計數(shù)	Work：吞吐量	服務(wù)器狀態(tài)變量
Com_select	SELECT 語句	Work：吞吐量	服務(wù)器狀態(tài)變量
Writes	插入，更新或刪除	Work：吞吐量	根據(jù)服務(wù)器狀態(tài)變量計算得到

在監(jiān)控任何系統(tǒng)時，你最關(guān)心的應(yīng)該是確保系統(tǒng)能夠高效地完成工作。數(shù)據(jù)庫的工作是運(yùn)行查詢，因此在本例中，你的首要任務(wù)是確保 MySQL 能夠如期執(zhí)行查詢。

MySQL 有一個名為?Questions?的內(nèi)部計數(shù)器（根據(jù) MySQL 用語，這是一個服務(wù)器狀態(tài)變量），客戶端每發(fā)送一個查詢語句，其值就會加一。由?Questions?指標(biāo)帶來的以客戶端為中心的視角常常比相關(guān)的Queries?計數(shù)器更容易解釋。作為存儲程序的一部分，后者也會計算已執(zhí)行語句的數(shù)量，以及諸如PREPARE?和?DEALLOCATE PREPARE?指令運(yùn)行的次數(shù)，作為服務(wù)器端預(yù)處理語句的一部分。

通過以下指令，查詢諸如?Questions?或?Com_select?服務(wù)器狀態(tài)變量的值：

SHOW?GLOBAL?STATUS?LIKE?"Questions"; +---------------+--------+ |?Variable_name?|?Value??| +---------------+--------+ |?Questions?????|?254408?| +---------------+--------+

你也可以監(jiān)控讀、寫指令的分解情況，從而更好地理解數(shù)據(jù)庫的工作負(fù)載、找到可能的瓶頸。通常，讀取查詢會由?Com_select?指標(biāo)抓取，而寫入查詢則可能增加三個狀態(tài)變量中某一個的值，這取決于具體的指令：

Writes?=?Com_insert?+?Com_update?+?Com_delete

應(yīng)該設(shè)置告警的指標(biāo)：Questions

當(dāng)前的查詢速率通常會有起伏，因此，如果基于固定的臨界值，查詢速率常常不是一個可操作的指標(biāo)。但是，對于查詢數(shù)量的突變設(shè)置告警非常重要——尤其是查詢量的驟降，可能暗示著某個嚴(yán)重的問題。

查詢性能

名稱描述指標(biāo)類型可用性

查詢運(yùn)行時間	每種模式下的平均運(yùn)行時間	Work：性能	性能模式查詢
查詢錯誤	出現(xiàn)錯誤的 SQL 語句數(shù)量	Work：錯誤	性能模式查詢
Slow_queries	超過可配置的long_query_time?限制的查詢數(shù)量	Work：性能	服務(wù)器狀態(tài)變量

MySQL 用戶監(jiān)控查詢延遲的方式有很多，既可以通過 MySQL 內(nèi)置的指標(biāo)，也可以通過查詢性能模式。從?MySQL 5.6.6?版本開始默認(rèn)啟用，MySQL 的?performance_schema?數(shù)據(jù)庫中的表格存儲著服務(wù)器事件與查詢執(zhí)行的低水平統(tǒng)計數(shù)據(jù)。

性能模式語句摘要

性能模式的?events_statements_summary_by_digest?表格中保存著許多關(guān)鍵指標(biāo)，抓取了與每條標(biāo)準(zhǔn)化語句有關(guān)的延遲、錯誤和查詢量信息。從該表截取的一行樣例顯示，某條語句被執(zhí)行了兩次，平均執(zhí)行用時為 325 毫秒（所有計時器的測量值都以微微秒為單位）：

***************************?1.?row?***************************?SCHEMA_NAME:?employees?????????????????????DIGEST:?0c6318da9de53353a3a1bacea70b4fce????????????????DIGEST_TEXT:?SELECT?*?FROM?`employees`?WHERE?`emp_no`?>???COUNT_STAR:?2?????????????SUM_TIMER_WAIT:?650358383000?????????????MIN_TIMER_WAIT:?292045159000?????????????AVG_TIMER_WAIT:?325179191000?????????????MAX_TIMER_WAIT:?358313224000??????????????SUM_LOCK_TIME:?520000000?????????????????SUM_ERRORS:?0???????????????SUM_WARNINGS:?0?????????SUM_ROWS_AFFECTED:?0??????????????SUM_ROWS_SENT:?520048??????????SUM_ROWS_EXAMINED:?520048...??????????SUM_NO_INDEX_USED:?0?????SUM_NO_GOOD_INDEX_USED:?0?????????????????FIRST_SEEN:?2016-03-24?14:25:32??????????????????LAST_SEEN:?2016-03-24?14:25:55

摘要表會標(biāo)準(zhǔn)化所有語句（如上面的?DIGEST_TEXT?一欄所示），忽略數(shù)據(jù)值，規(guī)范化空格與大小寫，因此，下面的兩條查詢會被認(rèn)為是相同的：

select?*?from?employees?where?emp_no?>200;
SELECT?*?FROM?employees?WHERE?emp_no?>?80000;

想要按模式抽取出以微秒為單位的平均運(yùn)行時間，你可以這樣查詢性能模式：

SELECT?schema_name,?SUM(count_star)?count?????,?ROUND(???(SUM(sum_timer_wait)?/?SUM(count_star))??????????????/?1000000)?AS?avg_microsec??FROM?performance_schema.events_statements_summary_by_digest?WHERE?schema_name?IS?NOT?NULL?GROUP?BY?schema_name; +--------------------+-------+--------------+ |?schema_name????????|?count?|?avg_microsec?| +--------------------+-------+--------------+ |?employees??????????|???223?|???????171940?| |?performance_schema?|????37?|????????20761?| |?sys????????????????|?????4?|??????????748?| +--------------------+-------+--------------+

相似地，按模式計算出現(xiàn)錯誤的語句總數(shù)，可以這么做：

SELECT?schema_name,?SUM(sum_errors)?err_countFROM?performance_schema.events_statements_summary_by_digest?WHERE?schema_name?IS?NOT?NULL?GROUP?BY?schema_name; +--------------------+-----------+ |?schema_name????????|?err_count?| +--------------------+-----------+ |?employees??????????|?????????8?| |?performance_schema?|?????????1?| |?sys????????????????|?????????3?| +--------------------+-----------+

sys 模式

用上面的方式查詢性能模式能以編程方式有效地從數(shù)據(jù)庫中檢索出指標(biāo)。然而，對于特別查詢或調(diào)查，使用 MySQL 的?sys 模式通常更為簡單。sys 模式以人們更易讀的格式提供了一個有條理的指標(biāo)集合，使得對應(yīng)的查詢更加簡單。例如，想要找出最慢的語句（運(yùn)行時間在 95 名開外）：

SELECT?*?FROM?sys.statements_with_runtimes_in_95th_percentile;

或者查看哪些標(biāo)準(zhǔn)化語句出現(xiàn)了錯誤：

SELECT?*?FROM?sys.statements_with_errors_or_warnings;

在 sys 模式的文檔中，詳細(xì)介紹了許多有用的例子。sys 模式在 MySQL 5.7.7 版本中是默認(rèn)包含的。不過，MySQL 5.6 用戶通過簡單的幾個指令就能安裝它。

慢查詢

除了性能模式與 sys 模式中豐富的性能數(shù)據(jù)，MySQL 還提供了一個?Slow_queries?計數(shù)器，每當(dāng)查詢的執(zhí)行時間超過?long_query_time?參數(shù)指定的值之后，該計數(shù)器就會增加。默認(rèn)情況下，該臨界值設(shè)置為 10 秒。

SHOW?VARIABLES?LIKE?'long_query_time'; +-----------------+-----------+ |?Variable_name???|?Value?????| +-----------------+-----------+ |?long_query_time?|?10.000000?| +-----------------+-----------+

long_query_time?參數(shù)的值可通過一條指令進(jìn)行調(diào)整。例如，將慢查詢臨界值設(shè)置為 5 秒：

SET?GLOBAL?long_query_time?=?5;

（請注意，你可能要關(guān)閉會話，再重新連接至數(shù)據(jù)庫，這些更改才能在會話層生效。）

調(diào)查查詢性能問題

如果你的查詢運(yùn)行得比預(yù)期要慢，很可能是某條最近修改的查詢在搗鬼。如果沒有發(fā)現(xiàn)特別緩慢的查詢，接下來就該評估系統(tǒng)級指標(biāo)，尋找核心資源（CPU，磁盤 I/O，內(nèi)存以及網(wǎng)絡(luò)）的限制。CPU 飽和與 I/O 瓶頸是常見的問題根源。你可能還想檢查?Innodb_row_lock_waits?指標(biāo)，該指標(biāo)記錄著 InnoDB 存儲引擎不得不停下來獲得某行的鎖定的次數(shù)。從 MySQL 5.5 版本起，InnoDB 就是默認(rèn)的存儲引擎，MySQL 對 InnoDB 表使用行級鎖定。

為了提高讀取與寫入操作的速度，許多用戶會想通過調(diào)整 InnoDB 使用的緩沖池大小來緩存表與索引數(shù)據(jù)。本文的第二部分會對監(jiān)控與調(diào)整緩沖池大小做詳細(xì)解讀。

應(yīng)該設(shè)置告警的指標(biāo)：

查詢運(yùn)行時間：管理關(guān)鍵數(shù)據(jù)庫的延遲至關(guān)重要。如果生產(chǎn)環(huán)境中數(shù)據(jù)庫的平均查詢運(yùn)行時間開始下降，應(yīng)該尋找數(shù)據(jù)庫實例的資源限制，行鎖或表鎖間可能的爭奪，以及客戶端查詢模式的變化情況。
查詢錯誤：查詢錯誤的猛增可能暗示著客戶端應(yīng)用或數(shù)據(jù)庫本身的問題。你可以使用 sys 模式快速查找可能導(dǎo)致問題的查詢。例如，列舉出返回錯誤數(shù)最多的 10 條標(biāo)準(zhǔn)化語句：

SELECT?*?FROM?sys.statements_with_errors_or_warnings? ORDER?BY?errors?DESC?LIMIT?10;

Slow_queries：如何定義慢查詢（并由此設(shè)置?long_query_time?參數(shù)）取決于你的用戶案例。但是，無論你如何定義 “慢”，你都會想知道慢查詢的數(shù)量是否超出了基準(zhǔn)水平。為了找出真正執(zhí)行緩慢的查詢，你可以詢問 sys 模式，或深入了解 MySQL 提供的慢查詢?nèi)罩?#xff08;該功能默認(rèn)是禁用的）。有關(guān)啟用并讀取慢查詢?nèi)罩镜母嘈判?#xff0c;請參考?MySQL 文檔。

連接

名稱描述指標(biāo)類型可用性

Threads_connected	當(dāng)前開放的連接	資源: 利用率	服務(wù)器狀態(tài)變量
Threads_running	當(dāng)前運(yùn)行的連接	資源: 利用率	服務(wù)器狀態(tài)變量
Connection_errors_internal	由服務(wù)器錯誤導(dǎo)致的失敗連接數(shù)	資源: 錯誤	服務(wù)器狀態(tài)變量
Aborted_connects	嘗試與服務(wù)器進(jìn)行連接結(jié)果失敗的次數(shù)	資源: 錯誤	服務(wù)器狀態(tài)變量
Connection_errors_max_connections	由?max_connections?限制導(dǎo)致的失敗連接數(shù)	資源: 錯誤	服務(wù)器狀態(tài)變量

檢查并設(shè)置連接限制

監(jiān)控客戶端連接情況相當(dāng)重要，因為一旦可用連接耗盡，新的客戶端連接就會遭到拒絕。MySQL 默認(rèn)的連接數(shù)限制為 151，可通過下面的查詢加以驗證：

SHOW?VARIABLES?LIKE?'max_connections'; +-----------------+-------+ |?Variable_name???|?Value?| +-----------------+-------+ |?max_connections?|?151???| +-----------------+-------+

MySQL 的文檔指出，健壯的服務(wù)器應(yīng)該能夠處理成百上千的連接數(shù)。

“常規(guī)情況下，Linux 或 Solaris 應(yīng)該能夠支持 500 到 1000 個同時連接。如果可用的 RAM 較大，且每個連接的工作量較低或目標(biāo)響應(yīng)時間較為寬松，則最多可處理 10000 個連接。而 Windows 能處理的連接數(shù)一般不超過 2048 個，這是由于該平臺上使用的 Posix 兼容層。”

連接數(shù)限制可以在系統(tǒng)運(yùn)行時進(jìn)行調(diào)整：

SET?GLOBAL?max_connections?=?200;

然而，此設(shè)置會在服務(wù)器重啟時恢復(fù)為默認(rèn)值。想要永久地改變連接數(shù)限制，可以在?my.cnf?配置文件中添加如下配置（查看本文了解如何定位配置文件）：

max_connections?=?200

監(jiān)控連接使用率

MySQL 提供了?Threads_connected?指標(biāo)以記錄連接的線程數(shù)——每個連接對應(yīng)一個線程。通過監(jiān)控該指標(biāo)與先前設(shè)置的連接限制，你可以確保服務(wù)器擁有足夠的容量處理新的連接。MySQL 還提供了Threads_running?指標(biāo)，幫助你分隔在任意時間正在積極處理查詢的線程與那些雖然可用但是閑置的連接。

如果服務(wù)器真的達(dá)到?max_connections?限制，它就會開始拒絕新的連接。在這種情況下，Connection_errors_max_connections?指標(biāo)就會開始增加，同時，追蹤所有失敗連接嘗試的Aborted_connects?指標(biāo)也會開始增加。

MySQL 提供了許多有關(guān)連接錯誤的指標(biāo)，幫助你調(diào)查連接問題。Connection_errors_internal?是個很值得關(guān)注的指標(biāo)，因為該指標(biāo)只會在錯誤源自服務(wù)器本身時增加。內(nèi)部錯誤可能反映了內(nèi)存不足狀況，或者服務(wù)器無法開啟新的線程。

應(yīng)該設(shè)置告警的指標(biāo)

Threads_connected：當(dāng)所有可用連接都被占用時，如果一個客戶端試圖連接至 MySQL，后者會返回 “Too many connections(連接數(shù)過多)” 錯誤，同時將Connection_errors_max_connections?的值增加。為了防止出現(xiàn)此類情況，你應(yīng)該監(jiān)控可用連接的數(shù)量，并確保其值保持在?max_connections?限制以內(nèi)。
Aborted_connects：如果該計數(shù)器在不斷增長，意味著用戶嘗試連接到數(shù)據(jù)庫的努力全都失敗了。此時，應(yīng)該借助?Connection_errors_max_connections?與 ?Connection_errors_internal?之類細(xì)粒度高的指標(biāo)調(diào)查該問題的根源。

緩沖池使用情況

名稱描述指標(biāo)類型可用性

Innodb_buffer_pool_pages_total	緩沖池中的總頁數(shù)	資源: 利用率	服務(wù)器狀態(tài)變量
緩沖池使用率	緩沖池中已使用頁數(shù)所占的比率	資源: 利用率	根據(jù)服務(wù)器狀態(tài)變量計算得到
Innodb_buffer_pool_read_requests	向緩沖池發(fā)送的請求	資源: 利用率	服務(wù)器狀態(tài)變量
Innodb_buffer_pool_reads	緩沖池?zé)o法滿足的請求	資源: 飽和度	服務(wù)器狀態(tài)變量

MySQL 默認(rèn)的存儲引擎 InnoDB 使用了一片稱為緩沖池的內(nèi)存區(qū)域，用于緩存數(shù)據(jù)表與索引的數(shù)據(jù)。緩沖池指標(biāo)屬于資源指標(biāo)，而非工作指標(biāo)，前者更多地用于調(diào)查（而非檢測）性能問題。如果數(shù)據(jù)庫性能開始下滑，而磁盤 I/O 在不斷攀升，擴(kuò)大緩沖池往往能帶來性能回升。

檢查緩沖池的大小

默認(rèn)設(shè)置下，緩沖池的大小通常相對較小，為 128MiB。不過，MySQL 建議可將其擴(kuò)大至專用數(shù)據(jù)庫服務(wù)器物理內(nèi)存的 80% 大小。然而，MySQL 也指出了一些注意事項：InnoDB 的內(nèi)存開銷可能提高超過緩沖池大小 10% 的內(nèi)存占用。并且，如果你耗盡了物理內(nèi)存，系統(tǒng)會求助于分頁，導(dǎo)致數(shù)據(jù)庫性能嚴(yán)重受損。

緩沖池也可以劃分為不同的區(qū)域，稱為實例。使用多個實例可以提高大容量 (多 GiB) 緩沖池的并發(fā)性。

緩沖池大小調(diào)整操作是分塊進(jìn)行的，緩沖池的大小必須為塊的大小乘以實例的數(shù)目再乘以某個倍數(shù)。

innodb_buffer_pool_size?=?N?*?innodb_buffer_pool_chunk_size?*?innodb_buffer_pool_instances

塊的默認(rèn)大小為 128 MiB，但是從 MySQL 5.7.5 開始可以自行配置。以上兩個參數(shù)的值都可以通過如下方式進(jìn)行檢查：

SHOW?GLOBAL?VARIABLES?LIKE?"innodb_buffer_pool_chunk_size"; SHOW?GLOBAL?VARIABLES?LIKE?"innodb_buffer_pool_instances";

如果?innodb_buffer_pool_chunk_size?查詢沒有返回結(jié)果，則表示在你使用的 MySQL 版本中此參數(shù)無法更改，其值為 128 MiB。

在服務(wù)器啟動時，你可以這樣設(shè)置緩沖池的大小以及實例的數(shù)量：

$?mysqld?--innodb_buffer_pool_size=8G?
--innodb_buffer_pool_instances=16

在 MySQL 5.7.5 版本，你可以通過?SET?指令在系統(tǒng)運(yùn)行時修改緩沖池的大小，并精確到字節(jié)數(shù)。例如，假設(shè)有兩個緩沖池實例，你可以將其總大小設(shè)置為 8 GiB，這樣每個實例的大小即為 4 GiB。

SET?GLOBAL?innodb_buffer_pool_size=8589934592;

關(guān)鍵的 InnoDB 緩沖池指標(biāo)

MySQL 提供了許多關(guān)于緩沖池及其利用率的指標(biāo)。其中一些有用的指標(biāo)能夠追蹤緩沖池的總大小，緩沖池的使用量，以及其處理讀取操作的效率。

指標(biāo)?Innodb_buffer_pool_read_requests?及?Innodb_buffer_pool_reads?對于理解緩沖池利用率都非常關(guān)鍵。Innodb_buffer_pool_read_requests?追蹤合理讀取請求的數(shù)量，而Innodb_buffer_pool_reads?追蹤緩沖池?zé)o法滿足，因而只能從磁盤讀取的請求數(shù)量。我們知道，從內(nèi)存讀取的速度比從磁盤讀取通常要快好幾個數(shù)量級，因此，如果?Innodb_buffer_pool_reads?的值開始增加，意味著數(shù)據(jù)庫性能大有問題。

緩沖池利用率是在考慮擴(kuò)大緩沖池之前應(yīng)該檢查的重要指標(biāo)。利用率指標(biāo)無法直接讀取，但是可以通過下面的方式簡單地計算得到：

(Innodb_buffer_pool_pages_total?-?Innodb_buffer_pool_pages_free)?/?Innodb_buffer_pool_pages_total

如果你的數(shù)據(jù)庫從磁盤進(jìn)行大量讀取，而緩沖池還有許多閑置空間，這可能是因為緩存最近才清理過，還處于熱身階段。如果你的緩沖池并未填滿，但能有效處理讀取請求，則說明你的數(shù)據(jù)工作集相當(dāng)適應(yīng)目前的內(nèi)存配置。

然而，較高的緩沖池利用率并不一定意味著壞消息，因為舊數(shù)據(jù)或不常使用的數(shù)據(jù)會根據(jù)?LRU 算法?自動從緩存中清理出去。但是，如果緩沖池?zé)o法有效滿足你的讀取工作量，這可能說明擴(kuò)大緩存的時機(jī)已至。

將緩沖池指標(biāo)轉(zhuǎn)化為字節(jié)

大多數(shù)緩沖池指標(biāo)都以內(nèi)存頁面為單位進(jìn)行記錄，但是這些指標(biāo)也可以轉(zhuǎn)化為字節(jié)，從而使其更容易與緩沖池的實際大小相關(guān)聯(lián)。例如，你可以使用追蹤緩沖池中內(nèi)存頁面總數(shù)的服務(wù)器狀態(tài)變量找出緩沖池的總大小（以字節(jié)為單位）：

Innodb_buffer_pool_pages_total?*?innodb_page_size

InnoDB 頁面大小是可調(diào)整的，但是默認(rèn)設(shè)置為 16 KiB，或 16,384 字節(jié)。你可以使用?SHOW VARIABLES?查詢了解其當(dāng)前值：

SHOW?VARIABLES?LIKE?"innodb_page_size";

結(jié)論

在本文中，我們介紹了許多你應(yīng)該加以監(jiān)控從而了解 MySQL 活動與性能表現(xiàn)的重要指標(biāo)。如果你正在躊躇 MySQL 監(jiān)控方案，抓取下面列出的指標(biāo)能讓你真正理解數(shù)據(jù)庫的使用模式與可能的限制情況。這些指標(biāo)也能幫助你發(fā)現(xiàn)，何時擴(kuò)展服務(wù)器內(nèi)存或?qū)?shù)據(jù)庫移至更為強(qiáng)大的主機(jī)，從而保持良好的應(yīng)用性能。

查詢吞吐量
查詢延遲與錯誤
客戶端連接與錯誤
緩沖池利用率

鳴謝

非常感謝來自?Oracle?的 Dave Stokes 與 VividCortex 的 Ewen Fortune，他們在本文發(fā)布之前提供了許多寶貴的反饋意見。

本文系?OneAPM?工程師編譯整理。OneAPM Cloud Insight?集監(jiān)控、管理、計算、協(xié)作、可視化于一身，幫助所有 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時間成本投入，讓運(yùn)維工作更加高效、簡單。想技術(shù)文章，請訪問?OneAPM 官方技術(shù)博客。

原文地址：https://www.datadoghq.com/blog/monitoring-mysql-performance-metrics/

http://blog.oneapm.com/apm-tech/754.html

http://blog.oneapm.com/apm-tech/755.html

總結(jié)

以上是生活随笔為你收集整理的MySQL 性能监控 4 大指标的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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

上一篇：《CCNP TSHOOT 300-135
下一篇： php 显示数据库操作错误,php操作m