禁用 performance schema 可行但不建议，需在 my.cnf 的 [mysqld] 段设 performance_schema = off 并重启生效；运行时不可修改，且禁用后 sys 视图、深度线程信息等功能全部失效。
禁用 Performance Schema 本身可行，但通常不建议——它默认启用、内存开销可控，且关闭后将彻底丢失所有运行时性能诊断能力。
performance_schema=OFF 是否真能禁用？
可以，但仅限启动时设置。MySQL 8.0 不支持 SET GLOBAL performance_schema = OFF，该变量是只读的。必须在 my.cnf 的 [mysqld] 段中写入：
[mysqld] performance_schema = OFF
重启后生效。验证方式是执行 SHOW VARIABLES LIKE 'performance_schema';，返回 OFF 即表示已禁用。
注意：若初始化失败（如内存不足），MySQL 会自动设为 OFF 并记录错误日志，此时不是你主动禁用，而是被动降级。
为什么禁用后可能看不到预期效果？
- 配置没被加载：MySQL 8.0 默认只读取
/etc/my.cnf、/etc/mysql/my.cnf等固定路径，/www/server/mysql/my.cnf或自定义路径需用--defaults-file显式指定 - 配置位置错误：写在
[client]或[mysql]段下完全无效，必须在[mysqld]段内 - 拼写或空格错误：
performance_schema = off（小写）、performance_schema= OFF（等号后多空格）均会被忽略，只认OFF或ON全大写 - 与
disabled_storage_engines混淆：后者管存储引擎，对PERFORMANCE_SCHEMA引擎完全不起作用
更推荐的做法：保留启用，但精简采集范围
真正影响性能的是采集粒度，不是开关本身。默认开启时，很多仪器（instruments）和消费者（consumers）其实处于闲置状态。可通过以下方式减负：
- 启动时禁用全部插桩：
--performance-schema-instrument='%=OFF'（写在my.cnf中为performance-schema-instrument = '%=OFF'） - 按需启用关键项，例如只开语句和等待：
performance-schema-instrument = 'statement/sql/%=ON'、performance-schema-instrument = 'wait/synch/mutex/%=ON' - 运行时关闭消费者表（非重启）：
CALL sys.ps_setup_disable_consumer('statement');，对应关闭events_statements_current等表的数据写入 - 避免误开内存监控：
memory/performance_schema/%类仪器无法禁用，但其他内存仪器可关，减少堆分配压力
禁用后最常被忽略的副作用
一旦 performance_schema = OFF，以下功能全部失效且无法恢复，除非重新启用并重启：
-
sysschema 中所有视图（如schema_table_statistics、host_summary_by_statement_type）查不到数据或报错 -
SHOW PROCESSLIST仍可用，但无法关联到线程内部阶段（stages）、锁等待链（data_lock_waits）等深度信息 - 备份工具（如
mysqldump）虽跳过performance_schema库，但依赖它的监控脚本会突然中断 - 某些 DBA 自动化巡检逻辑硬编码检查
performance_schema.events_waits_summary_global_by_event_name，直接报表不存在
真正需要“减负”的场景，往往不是关掉整个模块，而是关掉 wait/io/file/% 这类高频低价值采集项——它们占 I/O 插桩 70% 以上，却极少被用于线上问题定位。
