phpenv cpu 飙高主因是连接未释放、索引失效、慢日志路径错误及缓冲池过小；应调 wait_timeout=30、analyze table、确认 slow_query_log_file 可写、设 innodb_buffer_pool_size=256m 并重启验证。
phpEnv 是 Windows 下的轻量级 PHP/MySQL 开发环境，自带 MySQL 5.7 或 8.0（取决于版本），但默认配置极度保守，且不自动启用性能诊断功能。CPU 飙高时，mysqld.exe 占用常达 80%~100%，根本原因几乎总是「某条 SQL 在反复全表扫描」或「大量短连接堆积未释放」，而不是硬件或系统问题。
show processlist 看到大量 Sleep 状态但 CPU 还很高？检查 wait_timeout 和连接池
phpEnv 默认 wait_timeout=60，而很多 PHP 脚本（尤其用 mysqli 或旧版 PDO）没显式调用 close()，导致连接空闲后不立即断开，堆积在 Sleep 状态。这些线程本身不执行 SQL，但会持续占用内存和调度资源，高并发下拖垮 CPU。
- 进 phpEnv 控制面板 → MySQL → 配置 → 找到
my.ini，在[mysqld]段下添加或修改：wait_timeout=30和interactive_timeout=30 - 重启 MySQL 服务（必须点“重启 MySQL”按钮，不是仅重载配置）
- PHP 侧同步改代码：所有
new mysqli()后，确保在脚本末尾或 try-finally 中调用$mysqli->close()；PDO 则避免长期持有PDO实例，用完即 unset - 验证是否生效：执行
show variables like 'wait_timeout';，确认返回值是 30
EXPLAIN 显示 type=ALL 或 key=NULL？索引没生效或统计信息过期
phpEnv 自带的 MySQL 通常没跑过 ANALYZE TABLE，表统计信息陈旧，优化器误判「走索引比全表扫还慢」，直接放弃索引。哪怕你加了索引，EXPLAIN 仍显示 type=ALL。
- 先确认查询是否真走索引：执行
EXPLAIN SELECT * FROM users WHERE status = 1 AND created_at > '2025-01-01';，若key列为NULL，说明没命中 - 检查索引顺序：WHERE 条件是
status和created_at，但索引是(created_at, status)，则status无法利用最左前缀——应建(status, created_at) - 强制更新统计：
ANALYZE TABLE users;（对大表谨慎，phpEnv 环境一般表小，可放心） - 临时验证索引效果：加
FORCE INDEX (idx_status_time)再 EXPLAIN，如果type变成ref，说明优化器误判，需调整索引或升级 MySQL 版本（phpEnv 8.0 比 5.7 统计更准）
慢查询日志文件路径不对，log_slow_queries 已废弃
phpEnv 的 MySQL 5.7+ 已停用 log_slow_queries 变量，设了也无效。且默认日志路径常指向不存在的目录（如 C:/phpEnv/mysql/data/slow.log），导致开启后实际没写入，你以为关了慢查，其实它一直在后台默默全表扫。
- 登录 MySQL 后执行：
SHOW VARIABLES LIKE 'slow_query_log';确认是否为ON；若为OFF，运行SET GLOBAL slow_query_log = ON; - 查真实路径：
SHOW VARIABLES LIKE 'slow_query_log_file';—— 注意，phpEnv 常返回C:/phpEnv/mysql/data/DESKTOP-xxx-slow.log，确保该目录存在且 mysqld.exe 有写权限 - 设低阈值抓“中速”查询：
SET GLOBAL long_query_time = 0.1;（别用 1，phpEnv 环境单机跑，0.1 秒已算慢） - 日志启用后，用命令行查：进入
C:/phpEnv/mysql/data/目录，运行mysqldumpslow -s t -t 5 desktop-xxx-slow.log，看前 5 条耗时最长的
innodb_buffer_pool_size 小于 128M？内存配置严重不足
phpEnv 默认 innodb_buffer_pool_size=64M，甚至有些版本是 16M。一旦数据量超 50MB，InnoDB 就频繁刷盘、读盘，CPU 大量消耗在 IO 等待和上下文切换上，top 里看到 mysqld CPU 高，其实是磁盘瓶颈的假象。
- 打开
C:/phpEnv/mysql/my.ini，找到[mysqld]段，在其下添加：innodb_buffer_pool_size=256M（Win10/11 个人开发机，内存 ≥4G 时可用此值） - 删除原配置中可能存在的
innodb_buffer_pool_instances=1（旧版 phpEnv 有这行，会锁死缓冲池，新版 MySQL 要求 ≥ 1G 才建议设多实例） - 重启 MySQL 后执行：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';确认返回值是 268435456（即 256MB） - 注意：改完不重启 = 白改；改完不验证 = 不知道改没成功
phpEnv 环境下的 CPU 问题，90% 出在「连接没关」「索引白建」「日志路径错」「缓冲池太小」这四点。它不像生产环境要考虑集群、分库，排查路径非常线性：先 show processlist 看有没有卡住的查询，再查慢日志路径和内容，最后盯死 EXPLAIN 和 innodb_buffer_pool_size。任何跳过这四步直接调 sort_buffer_size 或 tmp_table_size 的操作，都是在掩盖真凶。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
