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表中的数据会不断增长，如果不及时清理，会占用大量的内存，影响性能。可以使用TRUNCATE TABLE语句来清理表。
- 使用过滤条件。在查询Performance Schema表时，使用过滤条件，只查询你需要的信息。
- 考虑使用采样。对于某些事件，可以采用采样的方式进行监控，而不是全部监控。
总而言之，Performance Schema是一个强大的性能分析工具，但需要谨慎使用，避免过度监控，影响生产环境的性能。
