Performance Schema (PFS)是MySQL 5.5引进的新特性，在MySQL5.6对这个特性的结构进行了大幅度的调整，从MySQL5.7至8.0，这个特性一直在持续改善。这是 MySQL 内置的诊断引擎，通过轻量级代码插桩（Instrumentation）实时采集数据库内部操作数据，为性能优化提供原子级观测能力。与传统慢查询日志不同，PFS 直接挂钩数据库内核，可追踪锁竞争、文件 I/O、内存分配等底层行为。
对于Performance Schema的使用，很多人持谨慎甚至是怀疑的态度，这主要是出于对其造成性能方面的消耗的疑虑。本文从第三方的测试报告、PFS的原理方面展示PFS对性能的影响，以及如何通过各种手段降低PFS对性能的消耗，使其在容忍的范围之内，使我们在不影响数据库的性能的情况下能享受PFS给我们带来的性能分析和诊断方面的收益。
1 从第三方的测试报告来看
oracle官方、Percona、AWS 都发布关于PFS对数据库性能影响的白皮书、测试报告或者生产基准，下面这个报告是在AWS上的测试数据，测试环境如下：
性能测试数据（256并发线程）见下面的表格：
上面的测试数据在基准情况下CPU利用率达到了78%，这是一个比较高的数值，大部分生产数据库CPU利用率经常在60%左右，平均延迟也不低，可以说是一个接近性能瓶颈的情况。在这种情况下基础监控的性能消耗在3%左右是一个可以接受的结果，开启全监控的性能消耗还是比较大的，达到14%，这个大概是无法接受的了。至于内存监控后系统消耗达到24%，『DeepSeek』从而得出了内存监控是高位项，是绝对不能开的。这应该是个靠不住的结论，如调整一下顺序，在基础监控后测试内存监控，可能会是另一个结果了。
