MYSQL使用performance_schema的注意事項(xiàng)有哪些

這篇文章主要介紹MYSQL使用performance_schema的注意事項(xiàng)有哪些，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

最近一段時(shí)間和MYSQL的 performance_schema 較勁，之前總結(jié)的比較散，沒有一個(gè)整體的觀，僅僅是細(xì)枝末葉的東西。本次的對(duì)performance_schema 從總體來看，看看未來（MYSQL 8），以后觀察MYSQL的性能問題需要什么改變。招招斃命其實(shí)是對(duì)老的監(jiān)控方法來用“吸引體”來 attractiveness。

從MYSQL5.6 開始performance_schema 越來越受到重視，但之前以一直有一種觀念就是，盡量不要開 performance_schema, 主要由以下原因，系統(tǒng)資源的消耗，和莫名的故障。導(dǎo)致 performance_schema 一直不是一個(gè)能被拿上桌面的系統(tǒng)性能觀察的通用方法。

如果是因?yàn)槌跗诘腂UG 的問題，不開啟performance_schema 我是同意的，而因?yàn)閜erformance_schema  消耗系統(tǒng)資源，而不開，這點(diǎn)其實(shí)我不敢茍同，一個(gè)系統(tǒng)的性能的監(jiān)控就是要一直進(jìn)行，并且既然是監(jiān)控一定是對(duì)系統(tǒng)有損耗的，為了不損耗，而不監(jiān)控，我不知道是哪門子的道理，如果系統(tǒng)的資源消耗是可控的，并且在初期的系統(tǒng)建設(shè)我們就將這部分資源算進(jìn)系統(tǒng)的消耗，不就可以了

到了MYSQL 5.7 performance_schema的監(jiān)控的方式和數(shù)據(jù)越來越重要，并且他變得設(shè)置更靈活。大致MYSQL的5.7的performance_schema 的控制要更方便。當(dāng)然也要有規(guī)劃。下面粗略的劃分了一下，其實(shí)還可以細(xì)分。下面就先對(duì)這些模塊的大致功能來說說。

1 Event 系列無疑是要占一大塊的份額，event 也足以可以進(jìn)行一個(gè)分類

 event 的劃分分為兩個(gè)維度， 1 統(tǒng)計(jì)信息的類別  2  統(tǒng)計(jì)信息的以時(shí)間為一個(gè)存放類別

從統(tǒng)計(jì)信息的類別看，stages , statements , transactions  ,waits 這四類，而存儲(chǔ)的方式也有當(dāng)前，歷史，較遠(yuǎn)的歷史信息這三類，當(dāng)然還有各種通過統(tǒng)計(jì)分析后，針對(duì)賬號(hào)，主機(jī)，線程，用戶，等等的信息summary.

這里舉一個(gè)列子，因?yàn)闁|西太多，如果每個(gè)都舉例子就變成說明書了。

events_transactions_current  我們以這個(gè)為例，通過下面的語句，你當(dāng)前的事務(wù)的運(yùn)行時(shí)間，你大概應(yīng)該有一個(gè)數(shù)了，thread_id 你也有了，如果你在能統(tǒng)計(jì)到你運(yùn)行時(shí)間對(duì)應(yīng)的 statement  ,那現(xiàn)在的慢查詢方式是不是可以準(zhǔn)備拋棄了（有一篇曾經(jīng)寫過關(guān)于傳統(tǒng)慢查詢的方式拋棄的文字）

select thread_id,event_name,state,trx_id,timeR_wait/1000000000000 as wait_second from events_transactions_current;

我們?cè)诩右岳茫覀兪遣皇强梢宰粉櫟?，一個(gè)列表，關(guān)于事務(wù)等待的時(shí)間的曲線圖（尤其對(duì)新上線的系統(tǒng)，通過曲線圖出現(xiàn)問題的第一時(shí)間就可以開始進(jìn)行故障的排查，而不必等呀等，而且二次開發(fā)一個(gè)慢查詢的系統(tǒng)我想也不是一件難事）

稍加改造，看看一點(diǎn)也不會(huì)比ORACLE 或者 SQL SERVER 某些功能差到哪里去。 （有所感悟，MYSQL（包括PG）的變化快，并且目前還處于一個(gè)急速上升期，和 ORACLE  SQL SERVER 不同，不緊跟是步步跟不上）

2 setup 

提到被詬病的 performance_schema 侵占MYSQL 性能的問題，雖然個(gè)人觀點(diǎn)，這并不是一個(gè)問題（除了BUG，我沒說BUG 不是問題）。 正常的性能侵占是應(yīng)該被容忍的，但我們也不能想怎樣就怎樣，我們也應(yīng)該有度的使用 performance_schema。

下面就說說怎來

從用戶的角度來進(jìn)行過濾，有些信息是可以不進(jìn)行記錄的，例如你認(rèn)為系統(tǒng)已經(jīng)穩(wěn)定，我就只需要對(duì)一些新的業(yè)務(wù)進(jìn)行監(jiān)控，那怎么辦？？

第一招，通過過濾應(yīng)用賬號(hào)來進(jìn)行過濾，通過setup_actors 表來控制

如果我們將默認(rèn)的全表同意收集，改為，通過賬號(hào)來進(jìn)行過濾，自然相對(duì)的信息收集會(huì)有一個(gè)。

      第二式，對(duì)某些事件的過濾， 有人愛吃甜，有人愛吃酸，你既可以對(duì)進(jìn)入的數(shù)據(jù)源進(jìn)行控制，也可以對(duì)進(jìn)入的信息進(jìn)行一個(gè)挑選。

參見上圖信息我們可以對(duì)目前setup_consumers 中列出的 events 的信息進(jìn)行過濾，直接UPDATE 就可以。

第三招，我們采用更細(xì)的粒度，對(duì)instruments 進(jìn)行信息的過濾。他有兩個(gè)過濾的粒度， 1 對(duì)于過濾類似 events_waits_summary_by_account_by_event_name 這樣的數(shù)據(jù)，我們對(duì)于他的控制可以從兩個(gè)方面來， ONE  event_name  我們可以將一些我們不需要的event 進(jìn)行過濾不在收集他的信息，另一種是對(duì)timer 進(jìn)行控制，將某些關(guān)于時(shí)間有關(guān)的信息收集（減小收集的頻度），進(jìn)行控制。

例如我們可以對(duì) wait/synch/mutex/sql/Event_scheduler::LOCK_scheduler_state這個(gè)事件的監(jiān)控停止，（因?yàn)镸YSQL 我們根本不用 event_scheduler ）

第四招，對(duì)數(shù)據(jù)庫的OBJECTS 進(jìn)行控制，通過  setup_objects我們可以對(duì)某些數(shù)據(jù)庫的項(xiàng)目進(jìn)行隔絕，例如，如果你數(shù)據(jù)庫中根本就沒有存儲(chǔ)過程，沒有函數(shù)，沒有trigger （一般都沒有） 自然我們就將這些性能的捕捉關(guān)停。

通過上面四招，我們可以大大化解performance_schema 對(duì)系統(tǒng)的資源消耗，同時(shí)也能通過performance_schema 進(jìn)行系統(tǒng)的監(jiān)控，何樂不為。當(dāng)然是寫語句，還是在CNF 中設(shè)置，那就要看這樣的需求穩(wěn)定不穩(wěn)定了。

另外還有一個(gè)MYSQL 早期版本不具備的功能，對(duì)于索引的一個(gè)使用usage rate占用 IO 的統(tǒng)計(jì)。

select * from table_io_waits_summary_by_index_usage

通過這個(gè)統(tǒng)計(jì)是可以對(duì)數(shù)據(jù)庫中的表使用索引的，以及沒有使用索引的I/O的分布情況有一個(gè)明確的數(shù)字作為指導(dǎo)，通過這個(gè)表可以詳細(xì)了解當(dāng)前的數(shù)據(jù)庫是不是可能存在缺少索引的情況。

今天就先到這里，其實(shí)關(guān)于performance_schema  里面的東西還有很多，如果感興趣可以繼續(xù)挖掘，對(duì)以后系統(tǒng)的性能判斷和問題的查找都有好處， 另外最近看到很多，12小時(shí)學(xué)懂MYSQL ， 21天成為MYSQL高手這樣的書籍和網(wǎng)課，其實(shí)倒不是對(duì)這些課程有什么意見，只是怕誤導(dǎo)一些人認(rèn)為MYSQL 很好學(xué)，幾天的功夫就OK 了，個(gè)人經(jīng)驗(yàn)包括 SQL SERVER  ORACLE ，PG ，MONGODB ，這些數(shù)據(jù)庫，都沒有那么容易，里面的“坑”， 都是通過成年累月的經(jīng)驗(yàn)和各種挨罵，提心吊膽過來的，短短的某個(gè)課程，可以讓不懂的人，知道某些知識(shí)，任何知識(shí)的積累都是通過不懈的努力和各種委屈組成的。

順便說一句，performance_schema  開啟使用查查 mysql bugs ，有些版本的MYSQL 開啟了后，會(huì)有OOM的情況。

以上是“MYSQL使用performance_schema的注意事項(xiàng)有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道！