phpenv 默认关闭 mysql 的 performance schema，需手动修改 my.ini 中 [mysqld] 段的 performance_schema = on 并重启对应 windows 服务（如 phpenv-mysql57），仅执行 sql 或改变量无效；启用后还需检查并开启 statements_digest consumer 和相关 instruments 才能获取语句摘要及 io 等事件数据。
phpEnv 默认关闭 MySQL 的 Performance Schema，必须手动修改配置并重启服务才能启用，仅改变量或执行 SQL 无效。
确认 phpEnv 中 MySQL 是否已启用 performance_schema
phpEnv 封装的是 Windows 下的 MySQL 二进制包（常见为 5.7 或 8.0），其默认配置通常禁用 performance_schema 以节省资源。直接登录后执行：
SHOW VARIABLES LIKE 'performance_schema';
如果返回 OFF，说明未启用。注意：phpEnv 界面里的“MySQL 配置”按钮打开的不一定是真实生效的配置文件，需手动定位。
- 真实配置文件路径通常是：
C:\phpEnv\phpEnv\mysql\my.ini（或C:\phpEnv\phpEnv\mysql\conf\my.ini，取决于 phpEnv 版本） - 务必检查
[mysqld]段落下是否有performance_schema = ON，且不能被后续同名配置覆盖 - 若存在
performance_schema = OFF或整行被注释掉，必须删掉或改为ON
修改 my.ini 后必须重启 MySQL 服务
phpEnv 的 MySQL 是以 Windows 服务方式运行的（服务名类似 phpenv-mysql57），不是简单重启 phpEnv 主程序就能生效。
- 在 phpEnv 主界面点击「服务」→「重启 MySQL」——这是最稳妥的方式
- 若失败，可手动在命令行执行：
net stop phpenv-mysql57 && net start phpenv-mysql57 -
SET GLOBAL performance_schema = ON会报错：Variable 'performance_schema' is a read only variable，因为它是启动参数，不可动态设置 - 重启后再次执行
SELECT @@performance_schema;，返回1才算真正开启
开了 performance_schema 但 events_statements_summary_by_digest 仍为空？
这是 phpEnv 用户最常卡住的地方：表存在、权限有、performance_schema=ON，但摘要表就是没数据。
- 根本原因：
statements_digest这个 consumer 默认是OFF，而摘要统计依赖它 - 检查命令：
SELECT * FROM performance_schema.setup_consumers WHERE NAME = 'statements_digest'; - 开启它：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'statements_digest'; - 同时确认 instruments 是否开：
SELECT * FROM performance_schema.setup_instruments WHERE NAME = 'statement/digest';（MySQL 8.0+ 默认YES，5.7 可能需要手动开） - 注意：该 consumer 只对开启之后新执行的语句生效，历史语句不会补入
为什么 phpEnv 下 wait/io 相关表始终查不到数据？
即使 performance_schema=ON，默认只开少量 instruments（如 statement/sql/select），wait/io/file/ 类事件默认全关。
- 查看当前 IO 采集状态：
SELECT * FROM performance_schema.setup_instruments WHERE NAME LIKE 'wait/io/file/%' AND ENABLED = 'YES'; - 临时开启（调试用）：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'wait/io/file/%'; - ⚠️ 生产环境慎用：IO instruments 开太多会导致 QPS 明显下降，尤其在 phpEnv 这类本地开发环境里磁盘 I/O 本就不稳定
- 更轻量的替代方案：优先查
events_statements_history或events_waits_current，它们对性能影响小得多
最关键的遗漏点是：很多人以为改了 my.ini 就完事，却忘了 phpEnv 的 MySQL 服务名可能带版本号（如 phpenv-mysql80），停错服务或没彻底停止旧进程，会导致配置不生效；另外，某些 phpEnv 旧版本打包的 MySQL 5.6 不支持 statements_digest consumer，必须升级到 5.7+ 才能用摘要分析功能。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
