MySQL启动后立刻停止的主因是配置、端口或权限异常，应优先查error.log和残留进程；常见问题包括3306端口被占、my.ini含不兼容参数、ibdata1锁死或权限不足，需结合日志、netstat、tasklist及服务恢复策略综合排查解决。
phpEnv 环境下 MySQL 服务启动后立刻停止，基本不是 phpEnv 本身的问题，而是 MySQL 进程在 Windows 上因配置、端口或权限异常被系统强制中止。直接查 error.log 和残留进程，比反复重装更有效。
检查 MySQL 错误日志（error.log）定位真实原因
phpEnv 的 MySQL 数据目录通常在 phpenv\mysql\data 下，进去找最新修改时间的 error.log（不是 mysql.err 或其他名字）。打开它，重点看末尾几行：
- 出现
Can't start server: Bind on TCP/IP port→ 端口被占（最常见） - 含
unknown option '--skip-federated'或类似参数错误 →my.ini里写了不支持的选项 - 报
InnoDB: Unable to lock ./ibdata1→ 上次异常退出没清理干净，或文件被其他进程锁定 - 有
Operating system error number 5→ 权限不足，MySQL 服务账户无法读写数据目录
确认 3306 端口是否被占用（Windows 必查）
管理员身份运行 CMD，执行这两条命令：
netstat -ano | findstr :3306
如果返回结果，记下最后一列的 PID；再执行：
立即学习“PHP免费学习笔记（深入）”；
tasklist | findstr <PID>
看是不是 mysqld.exe 自己占着——那说明上次没彻底退出；如果是 php.exe、nginx.exe 或其他进程占了，就得关掉它，或改 MySQL 的 port 配置。
别信“重启电脑就没事”，残留的 mysqld.exe 进程常驻后台，不手动杀掉，下次启动照样冲突。
检查 my.ini 配置是否兼容 phpEnv 的 MySQL 版本
phpEnv 多数集成 MySQL 5.7 或 8.0，但用户常从网上抄来的 my.ini 可能混入旧版废弃参数，比如：
-
skip-federated（MySQL 8.0 已移除） -
default-character-set=utf8（应为character-set-server=utf8mb4） -
innodb_buffer_pool_size设得过大（如 2G），而实际内存不足
建议：删掉 my.ini 中所有非必要配置，只保留最小可用集：
[mysqld] port=3306 basedir=../mysql datadir=../mysql/data character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci
保存后，用管理员 CMD 手动试启一次：../mysql/bin/mysqld --defaults-file=../mysql/my.ini --console，看控制台是否报错。
Windows 服务恢复策略设置（防闪退后无法自启）
即使 MySQL 启动失败，Windows 服务管理器默认“第一次失败：不操作”，导致你手动点启动，它又秒停。必须改服务恢复策略：
- Win+R 输入
services.msc→ 找到MySQL80或对应服务名 - 右键 → 属性 → 恢复选项卡
- “第一次失败”选“重新启动服务”，“重启动服务”填
0分钟 - “第二次失败”和“后续失败”也设为“重新启动服务”
这个设置能让服务在崩溃后立即拉起，给你留出查日志的时间，而不是卡在“正在启动…”状态里干等。
真正难搞的从来不是“怎么让它重启”，而是“为什么每次都要重启”。error.log 里的第一行错误，往往就是唯一线索；忽略它，只加守护脚本，等于给漏水的水管包胶带——水还在漏，只是暂时看不见。
