phpEnv中MySQL内存过高主因是innodb_buffer_pool_size默认按物理内存比例设置过大，小内存机器需手动调至512M（4GB内存）或256M（2GB内存），并同步调低max_connections=200、sort_buffer_size=262144等参数，改完必须重启服务并用SHOW VARIABLES验证生效。
phpEnv 本身不管理 MySQL 内存，它只是 Windows 下的 PHP + MySQL 一键集成环境（类似 phpStudy、XAMPP），真正吃内存的是 mysqld 进程。你看到“MySQL 占用高”，99% 是 innodb_buffer_pool_size 在小内存机器上默认设得过大导致的。
为什么 phpEnv 的 MySQL 启动就占 1.5GB+？
phpEnv 搭载的 MySQL（多为 5.7 或 8.0）在初始化时，会按物理内存比例自动设置 innodb_buffer_pool_size —— 比如你本机有 8GB 内存，它可能默认写成 4G，而你的 Windows 系统+Chrome+IDE 已经占掉 5GB，mysqld 一启动就被系统 OOM Killer 杀掉，或卡死在「正在启动」状态。
常见错误现象：
- phpEnv 面板显示 MySQL “未运行”，但任务管理器里能看到
mysqld.exe瞬间闪退 - 日志里出现
Out of memory或Cannot allocate memory for the buffer pool - 手动双击
mysql\bin\mysqld.exe报错：「系统资源不足，无法完成请求的服务」
直接改 my.ini：只动这一项就见效
phpEnv 的 MySQL 配置文件路径通常是：phpEnv\mysql\my.ini（不是 phpEnv\config\my.ini，后者常为空或无效）。
立即学习“PHP免费学习笔记（深入）”；
打开它，找到 [mysqld] 段，在下面新增或修改这一行：
innodb_buffer_pool_size = 512M
适用场景对应建议值：
- 2GB 内存机器 → 设为
256M - 4GB 内存机器 → 设为
512M或1G - 8GB 内存且只跑 phpEnv → 可设为
2G，但别超3G
⚠️ 注意：
- 不要写成
innodb_buffer_pool_size = 512MB（单位必须是M或G，不能带B） - 删掉其他重复的
innodb_buffer_pool_size行（有些 phpEnv 版本会在多个位置写，以最后一处为准） - 改完必须手动重启 MySQL 服务：进 phpEnv 面板 → MySQL → 「停止」→ 等几秒 → 「启动」；如果失败，去任务管理器结束所有
mysqld.exe，再点启动
连带要关的几个“内存放大器”参数
这些参数默认值在 phpEnv 的 my.ini 里往往没显式声明，MySQL 会用内置默认值，但在小内存 Windows 下极其危险：
-
max_connections：phpEnv 默认常设为1000，每个连接至少吃 2MB，1000 连接就是 2GB —— 建议改为200 -
sort_buffer_size和join_buffer_size：默认可能是 2M/4M，改成256K（即262144）更安全 -
query_cache_type：MySQL 5.7 及以前还存在，phpEnv 常默认开启，但对小站点纯属浪费 —— 设为0
示例片段（加在 [mysqld] 下）：
max_connections = 200 sort_buffer_size = 262144 join_buffer_size = 262144 query_cache_type = 0
改完还是慢？检查是不是 PHP 在拖后腿
phpEnv 里 PHP 和 MySQL 共用同一台 Windows 机器，PHP-FPM 或 Apache 的 php-cgi.exe 进程也可能吃光内存，尤其开了 Xdebug 或 OPcache 过大：
- 查看任务管理器 → 「详细信息」页，按内存排序，确认是
mysqld.exe还是php-cgi.exe占最多 - 如果是 PHP，重点调
opcache.memory_consumption（建议64，别设 256） - 关闭 phpEnv 面板里「PHP 调试模式」「Xdebug」等非必要扩展
- 检查 PHP 脚本是否循环查库、
SELECT *、没分页读大表 —— 这类问题会让 MySQL 临时表撑爆内存，和buffer_pool无关
最隐蔽的一点：Windows 下 MySQL 的 tmp_table_size 和 max_heap_table_size 默认仅 16M，复杂 GROUP BY 或 ORDER BY 会立刻落盘，查起来像卡死，其实是磁盘 IO 拖累 —— 可同步设为 64M
真正的瓶颈往往不在配置数字本身，而在你改完之后没验证它是否生效。每次重启后，连上 MySQL 执行：SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，看返回值是不是你写的 512M，而不是 4G —— 很多人改了文件却没生效，是因为路径错了、没重启、或者被其他 my.ini 覆盖了。
