如何從嘗試拋棄慢查詢分析MYSQL

本篇文章為大家展示了如何從嘗試拋棄慢查詢分析MYSQL ，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

MYSQL 的慢查詢一般是開發人員和DBA，獲取糟糕的SQL和可能缺少索引的一種方法，這樣的方法已經伴隨了MYSQL 一致到了MYSQL 5.7，但是否我們可以有其他的方法來獲取這樣的可用性的信息，進而減少對SLOW LOG的依賴，這是一個可以探討的問題。（這里不是要替代，而是抱著學習和探索的心態，也抱著順應發展的一種心態）

大部分關注MYSQL的 DBAer, 可能都知道從MYSQL5.6 開始MYSQL的風向標是靠近ORACLE的風格的，而眾所周知，ORALCE， SQL SERVER 這樣的數據庫是沒有例如MYSQL 這樣的慢查詢系統的。

那這里想說的是如果通過非慢查詢的方式來去找到一些系統問題，并且行之有效，當然這里并不是說要拋棄慢查詢，多一種方法，多一種程序設計者推薦給你的方法，自然是有很多好處的。

下面我們就此探討一下

1 問題：我做DDL時是否可以得知多長時間做完？

這個問題估計，如果知識不更新的MYSQL DBA回答起來會比較費勁，的確傳統是有方法的，但不是很準，具體怎么做，大家百度一下。(使用PT工具的活CQ的不在此次討論范圍)

今天想說的MYSQL 5.7 已經提供了準確的方法來提供你來知道你的DDL 到底做到哪里了，而不是一味的等待，等到那里算哪里。

那我們需要了解哪些知識

1 一個  alter 會產生哪些事件

    1 read PK and internal sort

    2 merge sort

    3 insert

    4 log apply index

    5 flush

    6 log apply table

    7 end

如何操作，首先我們先打開 performance_schema_setup_instrumets 和 performance_schema.setup_consumers

然后我們可以找一個大表 100萬以上的，去做一個DDL 的操作，然后執行下面的語句

我們可以很清晰的從上面的兩個圖中獲知，我們的DDL操作到了哪一步，到底運行到哪里，稍微動一點手腕就可以通過百分比的方式展示。

2 對某些慢語句的監控，以及互斥鎖的監控

對于只能在一個時間段中被獨占的資源，必然會產生互斥，而如何監控他們在原來的MYSQL 中是比較麻煩的，如何識別等待較長的事件，或對象則是一個需要解決的問題。

MYSQL可以通過 events_stages_summry_global_by_event_name，來監控某些等待，通過這些參數去了解MYSQL中可能正在經歷，或要面對的問題。

我們下面舉一些列子，通過以下方法就可以直接跨過 SLOW_LOG的方式

SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT       FROM performance_schema.events_statements_history_long where SQL_TEXT IS NOT NULL;

很明顯通過下面的查詢我們可以看到系統中運行的語句，并且很快得知每條語句的執行時間，從這點其實我們已經可以不通過慢查詢來獲得語句運行的時間，時間單位是秒。

我們可以通過對語句的分析，找到慢的語句而不使用慢查詢系統，同時我們也可以通過監控系統的設計，來繪制出一個數據庫系統的某些參數的變化，方便去查看一些突發事件，快速的發現問題。

select * from events_stages_summary_by_account_by_event_name where MIN_TIMER_WAIT <> 0 and user='app_collection';

上面的語句稍微變動一下，你就可以獲得MYSQL 某個數據庫的系統的等待時間，如果每幾秒取一次，對某些問題的發現是會有好處的。

上述內容就是如何從嘗試拋棄慢查詢分析MYSQL ，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。