MySQL 1067错误是Windows服务启动失败，本质是mysqld未通过初始化即退出；需用mysqld --console绕过服务封装查看实时错误，重点排查phpEnv自动生成的my.ini中路径含空格/中文未加引号、UTF-8 BOM编码、废弃参数（如skip-innodb）、log-error目录不存在及NTFS权限问题。
phpEnv 里 MySQL 启动报 1067，不是 MySQL 崩了，是它压根没活过初始化阶段——必须绕过服务封装，用 mysqld --console 看第一手错误输出。
为什么 phpEnv 的 my.ini 配置特别容易触发 1067
phpEnv 是便携式集成环境，my.ini 通常由脚本自动生成，但路径、编码、参数兼容性极易出错：
-
basedir和datadir路径含中文或空格（如C:\Program Files\phpEnv）却没加双引号，Windows 解析失败即退出 - 文件保存为 UTF-8 with BOM，
mysqld读到开头的 BOM 字节直接拒识，静默终止 - phpEnv 模板可能残留旧版参数，比如
skip-innodb（MySQL 5.7+ 已移除）或拼错的default-storage-engin -
log-error指向不存在的目录（如D:\phpEnv\logs\mysql.err），而该路径根本没创建，MySQL 初始化失败后连日志都写不了
不重启服务也能立刻定位问题：强制控制台输出
phpEnv 启动 MySQL 本质是调用 mysqld --defaults-file="path/to/my.ini" 注册为 Windows 服务。但服务启动失败时，错误被吞掉。正确做法是手动模拟启动流程，把错误打到终端：
以管理员身份打开 CMD，cd 到 phpEnv 的 mysql\bin 目录，执行：
立即学习“PHP免费学习笔记（深入）”；
mysqld --defaults-file="C:\phpEnv\mysql\my.ini" --console
注意三点：
-
--console是关键，它禁用日志重定向，让 InnoDB 初始化失败、插件加载异常、配置语法错误等全部暴露在屏幕上 - 路径必须用双引号包裹，且反斜杠要写成
\（Windows 原生支持），不能写成/ - 如果提示
Can't find file: '.\mysql\plugin.frm'或unknown variable 'skip-federated'，说明datadir错了或配置项已废弃
phpEnv 环境下最常被忽略的权限和路径陷阱
phpEnv 默认用 LocalSystem 运行 MySQL 服务，但它对路径敏感度比你想象中高：
-
datadir（通常是C:\phpEnv\mysql\data）必须存在，且包含mysql、performance_schema等系统库子目录；若为空或只有你自己的库文件夹，InnoDB 会拒绝启动 - 整个
mysql文件夹右键 → 属性 → 安全 → 编辑 → 添加SYSTEM用户，并勾选「完全控制」；别只信「继承」，手动点进去确认 - 如果改过端口（如
port=3307），检查是否被 phpEnv 自带的其他组件（如 MariaDB 实例）或 Docker 占用：netstat -ano | findstr :3307 - 删
ib_logfile0、ib_logfile1、ibdata1前先备份data下所有数据库名对应的文件夹（如myapp），否则初始化后数据全丢
修复后重注册服务前，必须验证配置有效性
phpEnv 的服务注册命令（mysqld --install）不校验配置，错配照样注册成功，启动时才爆 1067。安全做法是先验证：
mysqld --defaults-file="C:\phpEnv\mysql\my.ini" --validate-config
返回 Configuration file OK. 才算过关。若报错，按提示逐行检查 my.ini —— 尤其注意空行、末尾多余空格、注释符 # 后有没有非法字符。
真正棘手的是错误日志里只打印 Aborting... 就退出，连模块名都不带，这种往往卡在 NTFS 权限或路径解析最底层，得回到 --console 输出逐字盯。
