MySQL 5.5 增加了 performance_schema 和 information_schema 数据库。正如我们在上周的文章看到的那样，information_schema 中的表包含有关表、插件、分区、进程列表、状态和全局变量的统计信息。顾名思义，performance_schema 的表可用于提高 MySQL 实例的性能。如何做到这一点将成为今天的主题。 就像上一篇文章一样，我们将使用 Navicat Premium 来演示如何运行各种查询。
简要概述
Performance Schema 是一种用于监控 MySQL 服务器在低级别执行的工具。Performance Schema 的存储引擎使用“performance_schema”名称，以便轻松地将其与其他存储引擎区分开来。拥有自己的引擎能令访问有关服务器执行的信息时，将对服务器性能的影响減到最小。此外，它使用视图或临时表，以降低永久磁盘存储的使用量。最后，内存分配会在服务器启动时全部完成，因此不需要进一步的内存重新分配或大小调整，这极大地提升性能。
从MySQL 5.6.6开始，默认情况下 Performance Schema 是已启用。在该版本之前，默认情况下是已禁用。你可以使用以下语句验证其状态：
如果需要启用它，可以随时使用 --performance-schema=ON 标志来启动服务器。
现在，让我们了解 performance_schema 的一些实际用途。
互斥锁（Ｍutex）和线程（Thread）的速成课程
互斥锁是代码中使用的同步机制，以强制在给定时间只有一个线程可以访问某些公共资源。这些资源可以说是被互斥锁“保护”。“Mutex”这个词本身是“mutual exclusion”的缩写，亦是“mutex variable”的非正式缩写。在 MySQL 中，它是 InnoDB 用于表示和强制执行对内部内存数据结构的独占访问锁的低级别对象。以下是它的工作原理：
当锁定已获取后，任何其他进程、线程等将被阻止获取相同的锁定。在 InnoDB 中，多个执行线程访问共享数据结构。InnoDB 将这些访问与其自己的互斥锁和读写锁同步。当在服务器中执行的两个线程（例如，两个用户会话同时执行一个查询）需要访问相同的资源（例如文件、缓冲区或某些数据）时，这两个线程将相互竞争，因此获取互斥锁锁定的第一个查询将导致另一个查询等到第一个查询完成并解锁互斥锁。如果第一个线程需要很长时间才能完成，那么它可能会延误其他进程的执行。
一些有用的查询
所有互斥锁都列在 Performance Schema 的 mutex_instances 表中，这对调查性能瓶颈非常有帮助。而 mutex_instances.LOCKED_BY_THREAD_ID 列和 rwlock_instances.WRITE_LOCKED_BY_THREAD_ID 列对于调查性能瓶颈或死锁非常重要。以下是如何使用它们：
假设 thread 1 在等待一个互斥锁时停滞。
你可以确定线程正在等待什么：
假设查询结果显示线程正在等待在 events_waits_current.OBJECT_INSTANCE_BEGIN 找到的 mutex A。
你可以确定持有 mutex A 的线程：
假设查询结果显示是 thread 2 持有 mutex A，如 mutex_instances.LOCKED_BY_THREAD_ID 所示。
你可以使用此查询查看 thread 2正在执行的操作：
总结
在今天的文章中，我们学习了如何使用 Performance Schema 来诊断 MySQL 8 中的瓶颈和/或死锁。有一個更简单的方法是使用 Navicat Monitor。我们将会在下次探索这个软件。它有一个查询分析器，可以显示所有正在运行的查询的摘要信息，并能轻松地检测到死锁，例如两个或多个查询互相永久阻止对方。
