mysql查詢性能監控的核心在于啟用并合理配置performance schema以收集關鍵事件數據。首先，檢查performance schema是否啟用，若未啟用則在配置文件中設置performance_schema=on并重啟服務；其次，通過修改setup_instruments和setup_consumers表來開啟所需事件的監控，如sql語句執行時間等；最后，查詢events_statements_summary_global_by_event_name等表以分析性能瓶頸，并記得及時關閉不必要的監控以減少開銷。
mysql查詢性能監控的核心在于理解和利用Performance Schema。它就像一個內置的性能分析器，能幫你揪出數據庫的瓶頸。與其說是“如何”，不如說是“如何更好地”利用它，畢竟默認情況下，它已經開啟，只是需要我們更深入地挖掘。
解決方案
Performance Schema的工作原理是收集MySQL服務器運行時的各種事件信息，比如sql語句執行時間、鎖等待、I/O操作等等。這些信息存儲在Performance Schema的表中，我們可以通過查詢這些表來分析性能問題。
首先，確認Performance Schema是否啟用：
SELECT @@performance_schema;
如果結果是1，那么就沒問題。如果是0，你需要修改MySQL配置文件（my.cnf或my.ini），添加或修改以下行：
performance_schema=ON
然后重啟MySQL服務。
接下來，就是配置Performance Schema，哪些事件需要收集，收集到什么級別。這涉及到修改setup_instruments和setup_consumers表。
例如，你想監控所有SQL語句的執行時間，可以這樣設置：
UPDATE performance_schema.setup_instruments SET enabled = 'YES', timed = 'YES' WHERE name LIKE 'statement/%'; UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name LIKE '%statement%';
setup_instruments控制收集哪些事件，timed = ‘YES’表示記錄事件的耗時。setup_consumers控制將事件信息存儲到哪些表中。
最后，查詢Performance Schema表來分析性能。幾個常用的表：
- events_statements_summary_global_by_event_name: 按照事件名稱匯總的SQL語句執行信息。
- events_statements_current: 當前正在執行的SQL語句。
- events_waits_summary_global_by_event_name: 按照事件名稱匯總的等待事件信息。
舉個例子，找出執行時間最長的SQL語句：
SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WaiT FROM performance_schema.events_statements_summary_global_by_event_name WHERE EVENT_NAME LIKE 'statement/%' ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
記住，Performance Schema會帶來一定的性能開銷，所以不要過度收集信息。找到瓶頸后，及時關閉不必要的監控。
如何解讀Performance Schema中的時間單位？
Performance Schema中使用皮秒（picosecond）作為時間單位，這可能會讓初學者感到困惑。記住，1秒 = 1,000,000,000,000 皮秒。所以，當你看到一個很大的數字時，不要慌，除以1,000,000,000,000就能得到秒數了。當然，MySQL也提供了函數來進行轉換，比如convert_tz，雖然它主要是用于時區轉換，但也可以用于時間單位的轉換。更常見的是，直接用你的編程語言處理這些數據，進行單位轉換和格式化，讓結果更易讀。實際上，理解皮秒的真正價值在于它提供的高精度，這對于定位非常細微的性能瓶頸至關重要。
如何使用Performance Schema診斷死鎖？
死鎖是數據庫性能的噩夢。Performance Schema可以幫助你診斷死鎖。首先，確保wait/lock/table/sql/handler等相關instrument被啟用。然后，查看events_waits_current表，它會顯示當前正在等待的事件。如果發現有大量的線程都在等待同一個鎖，那么很可能發生了死鎖。更進一步，可以結合data_locks和data_lock_waits表，查看哪些事務正在持有鎖，哪些事務正在等待鎖。通過分析這些信息，可以找到死鎖的根源，并采取相應的措施，比如優化SQL語句、調整事務隔離級別等等。死鎖的診斷往往需要結合應用代碼和數據庫日志進行綜合分析，Performance Schema只是提供了一個重要的視角。
Performance Schema對生產環境的影響有多大？如何最小化性能開銷？
這是個關鍵問題。Performance Schema確實會帶來性能開銷，但通常情況下，這個開銷是可以接受的。默認配置下，Performance Schema只會收集少量的信息，對性能的影響很小。但是，如果你開啟了大量的監控，或者監控的粒度過細，那么性能開銷就會顯著增加。
要最小化性能開銷，可以采取以下措施：
- 只開啟必要的監控。不要貪多，只監控你真正關心的事件。
- 降低監控的粒度。比如，不要監控每一條SQL語句的執行時間，而是只監控執行時間超過某個閾值的SQL語句。
- 定期清理Performance Schema表。Performance Schema表中的數據會不斷增長，如果不及時清理，會占用大量的內存，影響性能?？梢允褂肨RUNCATE TABLE語句來清理表。
- 使用過濾條件。在查詢Performance Schema表時，使用過濾條件，只查詢你需要的信息。
- 考慮使用采樣。對于某些事件，可以采用采樣的方式進行監控，而不是全部監控。
總而言之，Performance Schema是一個強大的性能分析工具，但需要謹慎使用，避免過度監控，影響生產環境的性能。
