MySQL 中的性能模式（Performance Schema）是一个内置的、运行在数据库内核层的实时监控系统，它不是日志，也不是插件，而是一套由内存表构成的“性能数据接口”。它的核心作用是让管理员和开发者能直接观察 MySQL 服务器内部正在发生的操作——比如某条 SQL 正在等锁、某个线程卡在磁盘 I/O、索引为何没被用上。
它本质上是一个只读的系统数据库
performance_schema 是 MySQL 启动时自动创建的数据库，和
information_schema、
mysql并列。但它里面的表（如
events_statements_history、
events_waits_current）不是磁盘文件，而是内存中动态生成的虚拟表： 你不能对它们执行 INSERT/UPDATE/DELETE 没有 .ibd 或 .frm 数据文件（只有空的 .frm 结构文件） 重启后所有数据清空，启动时重新采集 查询时，MySQL 实时从内存 instrumentation 点拉取当前状态返回
它专注的是“性能事件”，不是元数据或业务数据
和
information_schema（查表结构、列名、权限）不同，performance_schema 关注的是“发生了什么、耗时多少、谁在等、等什么”： SQL 执行阶段：parsing、sorting、sending data 等待事件：mutex 锁、file I/O、table lock、socket read 线程行为：活跃线程数、每个线程最近执行的 10 条语句 资源使用：内存分配、临时表创建、全表扫描次数
它默认开启但常被云环境关闭
MySQL 5.6+ 默认启用 performance_schema，但在多数云数据库（如阿里云 RDS、腾讯云 CDB）中为节省资源，默认设为 OFF：
确认是否开启：SHOW VARIABLES LIKE 'performance_schema';→ 返回
ON才可用 开启方式：必须在
my.cnf的
[mysqld]段添加
performance_schema=ON，然后重启 mysqld 注意：这是只读启动参数，无法在线动态开启
它靠配置表控制采集粒度和开销
performance_schema 本身轻量，但具体采集哪些内容，由两张关键配置表决定：
setup_instruments：开关各类事件采集（如
statement/sql/select、
wait/io/file/innodb/innodb_data_file）
setup_consumers：决定采集结果是否写入历史表（如关掉
events_statements_history可大幅降低内存占用） 修改后立即生效，无需重启
