MYSQL使用performance_schema的注意事項有哪些

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

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

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

如果是因為初期的BUG 的問題，不開啟performance_schema 我是同意的，而因為performance_schema  消耗系統資源，而不開，這點其實我不敢茍同，一個系統的性能的監控就是要一直進行，并且既然是監控一定是對系統有損耗的，為了不損耗，而不監控，我不知道是哪門子的道理，如果系統的資源消耗是可控的，并且在初期的系統建設我們就將這部分資源算進系統的消耗，不就可以了

到了MYSQL 5.7 performance_schema的監控的方式和數據越來越重要，并且他變得設置更靈活。大致MYSQL的5.7的performance_schema 的控制要更方便。當然也要有規劃。下面粗略的劃分了一下，其實還可以細分。下面就先對這些模塊的大致功能來說說。

1 Event 系列無疑是要占一大塊的份額，event 也足以可以進行一個分類

 event 的劃分分為兩個維度， 1 統計信息的類別  2  統計信息的以時間為一個存放類別

從統計信息的類別看，stages , statements , transactions  ,waits 這四類，而存儲的方式也有當前，歷史，較遠的歷史信息這三類，當然還有各種通過統計分析后，針對賬號，主機，線程，用戶，等等的信息summary.

這里舉一個列子，因為東西太多，如果每個都舉例子就變成說明書了。

events_transactions_current  我們以這個為例，通過下面的語句，你當前的事務的運行時間，你大概應該有一個數了，thread_id 你也有了，如果你在能統計到你運行時間對應的 statement  ,那現在的慢查詢方式是不是可以準備拋棄了（有一篇曾經寫過關于傳統慢查詢的方式拋棄的文字）

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

我們在加以利用，我們是不是可以追蹤到，一個列表，關于事務等待的時間的曲線圖（尤其對新上線的系統，通過曲線圖出現問題的第一時間就可以開始進行故障的排查，而不必等呀等，而且二次開發一個慢查詢的系統我想也不是一件難事）

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

2 setup 

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

下面就說說怎來

從用戶的角度來進行過濾，有些信息是可以不進行記錄的，例如你認為系統已經穩定，我就只需要對一些新的業務進行監控，那怎么辦？？

第一招，通過過濾應用賬號來進行過濾，通過setup_actors 表來控制

如果我們將默認的全表同意收集，改為，通過賬號來進行過濾，自然相對的信息收集會有一個。

      第二式，對某些事件的過濾， 有人愛吃甜，有人愛吃酸，你既可以對進入的數據源進行控制，也可以對進入的信息進行一個挑選。

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

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

例如我們可以對 wait/synch/mutex/sql/Event_scheduler::LOCK_scheduler_state這個事件的監控停止，（因為MYSQL 我們根本不用 event_scheduler ）

第四招，對數據庫的OBJECTS 進行控制，通過  setup_objects我們可以對某些數據庫的項目進行隔絕，例如，如果你數據庫中根本就沒有存儲過程，沒有函數，沒有trigger （一般都沒有） 自然我們就將這些性能的捕捉關停。

通過上面四招，我們可以大大化解performance_schema 對系統的資源消耗，同時也能通過performance_schema 進行系統的監控，何樂不為。當然是寫語句，還是在CNF 中設置，那就要看這樣的需求穩定不穩定了。

另外還有一個MYSQL 早期版本不具備的功能，對于索引的一個使用usage rate占用 IO 的統計。

select * from table_io_waits_summary_by_index_usage

通過這個統計是可以對數據庫中的表使用索引的，以及沒有使用索引的I/O的分布情況有一個明確的數字作為指導，通過這個表可以詳細了解當前的數據庫是不是可能存在缺少索引的情況。

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

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

以上是“MYSQL使用performance_schema的注意事項有哪些”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！