先查日志文件，再查端口占用、权限、配置文件、系统资源及服务名是否匹配，最后尝试修改登录账户或innodb_flush_method参数。
MySQL服务启动失败但没报错，先看日志文件
没报错≠没问题，phpEnv 启动 MySQL 失败时最常被忽略的就是直接跳过日志。错误信息全在 mysql_error.log 或主机名.err 文件里，路径通常是 phpEnv 安装目录下的 MySQL\data\ 子目录。
打开这个文件，重点看最后 10 行。常见线索包括：
-
InnoDB: Unable to lock .\ibdata1→ 上次 MySQL 没正常关闭，需删掉ib_logfile0、ib_logfile1（不是ibdata1！删它会丢数据） -
Can't start server : Bind on TCP/IP port. Got error: 10048→ 端口确实被占，不是“可能”，是确定 -
File './mysql/plugin.MYD' not found→datadir路径错或权限不足，Windows 下尤其要注意目录是否被系统隐藏或只读
netstat 查 3306 端口谁在用，别猜
以管理员身份运行 CMD，执行：netstat -ano | findstr :3306。如果有输出，第三列是 PID，拿它去任务管理器“详细信息”页筛选，看进程名。
常见真凶：
立即学习“PHP免费学习笔记（深入）”；
-
Skype.exe：老版本默认抢 3306，关掉 Skype 或进设置 → 高级 → 连接 → 取消勾选“使用端口 80 和 443 作为替代” -
mysqld.exe（另一个 MySQL 实例）：比如你本机装过 MySQL Server，服务名可能是MySQL80、MySQL57，不是mysql -
sqlservr.exe：SQL Server 的默认 TCP 端口也是 3306，哪怕没启动服务，也可能监听中
确认后用 taskkill /f /pid <pid></pid> 杀掉，再试启动 phpEnv 的 MySQL。
sc delete mysql 不管用？查准服务名再删
phpEnv 注册的 MySQL 服务名不一定是 mysql。进 Windows 服务管理器（services.msc），找所有带 “mysql”、“mariadb”、“phpenv” 字样的服务，记下完整名称，比如 phpenv-mysql57 或 MySQL-PE。
然后管理员 CMD 执行：
-
sc queryex "phpenv-mysql57"→ 确认状态和 PID -
sc delete "phpenv-mysql57"→ 名字必须完全一致，带引号 - 再到 phpEnv 的 MySQL
bin目录下运行：mysqld --install "phpenv-mysql57" --defaults-file="..\my.ini"→ 补全配置路径，否则注册的服务会找不到配置
my.ini 里加了 innodb_flush_method=normal 是临时解法
某些 Windows 系统（尤其是 NTFS 带压缩/BitLocker 加密/非系统盘挂载的 SSD）下，InnoDB 默认的 innodb_flush_method（如 unbuffered 或空值）会导致初始化失败，错误日志里可能只显示“服务启动后停止”，没其他线索。
在 my.ini 的 [mysqld] 区块末尾加一行：
innodb_flush_method=normal
注意：
- 仅 Windows 有效，Linux 不认这个值
- 性能略降（绕过 Direct I/O），但比启不来强；生产环境应排查磁盘策略，而非长期依赖此配置
- 加完必须重启服务，不是重载配置
真正难搞的是日志里没明确报错、端口也没冲突、服务名也删干净了，却还是 1053 错误——这时候得去服务属性里把登录账户改成 LocalSystem，而不是当前用户或 Administrator，Windows 权限模型在这类绿色版环境里很挑人。
