答案是用mysqld --console强制输出启动日志定位初始化卡点。该错误本质是mysqld在windows服务模式下未完成初始化即退出，需检查my.ini路径/编码、basedir/datadir权限、废弃参数及innodb表空间状态。
直接用 mysqld --console 启动，看第一行错误输出——别等 Windows 服务日志，它根本不会生成。
为什么 mysqld --console 是第一步
错误 1067 不是 MySQL 报的错，是 Windows 服务管理器发现 mysqld.exe 启动几秒内就退出了，连初始化都没完成。此时 mysqld.err 日志往往压根没创建，因为写日志本身就需要初始化成功。
- 以管理员身份打开 CMD，
cd到 MySQL 的bin目录（如D:\phpEnv\phpEnv\mysql\bin） - 执行：
mysqld --defaults-file="D:\phpEnv\phpEnv\mysql\my.ini" --console - 终端立刻退出？第一行就是致命原因，比如：
Can't find messagefile 'D:/phpEnv/phpEnv/mysql/share/errmsg.sys'（basedir错）、InnoDB: Unable to open the first datafile（datadir无权限或路径不存在）、Unknown variable 'skip-federated'（用了已废弃参数）
检查 my.ini 路径、编码和废弃参数
my.ini 是 1067 最常翻车的地方，尤其在 phpEnv 或免安装版中：
-
basedir和datadir路径含空格或中文时，必须用双引号包裹；但更稳妥的是迁移到无空格路径（如D:/mysql），避免引号解析不稳定 - 统一用正斜杠
/，不要混用反斜杠\——mysqld对路径分隔符敏感 - MySQL 5.7+ 已移除的参数会直接导致启动失败：
skip-innodb、innodb_additional_mem_pool_size、query_cache_type、default-storage-engin（拼错）等，删掉或注释掉 - 文件编码必须是 ANSI 或 UTF-8 无 BOM；用记事本另存为时选“ANSI”，Notepad++ 里确认编码不是 UTF-8-BOM
验证 datadir 权限和服务账户访问能力
即使路径存在，权限不对也会静默失败：
- 右键
datadir文件夹（如D:\phpEnv\phpEnv\mysql\data）→「属性」→「安全」→ 确认服务运行账户（默认是LocalSystem，或你手动指定的用户）有「完全控制」权限 - 别依赖「继承自父项」——手动点「编辑」，勾选「修改」「写入」「列出文件夹内容」
- 如果改过服务账户（比如设成某个域用户），该账户必须能访问
basedir和datadir下所有子目录；NTFS 权限不跨卷，网络路径基本不可用 -
log-error指向的目录也必须可写，否则连错误日志都打不开，形成“无日志→无法诊断→瞎猜”的死循环
端口冲突和 ib_logfile 状态容易被忽略
这两类问题不会在 --console 里直接报错，但会导致进程卡住后被 Windows 强杀：
- 查端口占用：
netstat -ano | findstr :3306；若被占用，要么杀掉对应 PID 的进程，要么在my.ini中改port=3307 -
innodb_log_file_size值大于现有ib_logfile*文件实际大小，InnoDB 初始化会拒绝启动；可临时删掉ib_logfile0、ib_logfile1（保留ibdata1和数据库子目录），再重试 - 如果
--console输出停在Aborting就退出，连模块名都没加载出来，大概率是basedir下缺share/errmsg.sys或bin/mysqld.exe找不到依赖 DLL（如msvcp140.dll）
真正棘手的情况是：你修复了路径和权限，--console 也不报错了，但注册为服务后仍 1067——这时要检查服务注册命令是否带了 --defaults-file，以及 Windows 服务属性里“登录”选项卡是否误改了账户。服务模式下，哪怕一个隐藏的 BOM 字符或路径末尾多了一个空格，都会让整个初始化流程在毫秒级内静默崩溃。
