答案是用mysqld --console强制输出启动日志定位初始化卡点。该错误本质是mysqld在Windows服务模式下未完成初始化即退出，需检查my.ini路径/编码、basedir/datadir权限、废弃参数及InnoDB表空间状态。
直接看 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指向的目录也必须可写，否则连错误日志都打不开，形成“无日志→无法诊断→瞎猜”的死循环
排查端口冲突和 InnoDB 表空间状态
这两类问题不会在 --console 里直接报错，但会导致进程卡住后被 Windows 强杀：
- 查端口占用：
netstat -ano | findstr :3306，若有 PID，去任务管理器「详细信息」页找对应进程；解决方式：停掉冲突服务，或在my.ini的[mysqld]段加port=3307 - InnoDB 表空间损坏常发生在异常关机后，现象是
--console输出卡在InnoDB: Starting crash recovery...或直接Aborting；此时可临时加innodb_force_recovery=1（值 1–6，从最小开始试），仅用于导出数据，不能长期启用 -
innodb_log_file_size值大于现有ib_logfile0实际大小时，InnoDB 拒绝启动；要么删掉ib_logfile*（确保innodb_fast_shutdown=0已执行过正常关闭），要么调小配置值匹配现有文件
真正棘手的是那些连 --console 都没输出就退出的情况——大概率是 my.ini 路径错、文件编码含 BOM、或 basedir 下根本找不到 mysqld.exe 所需的 DLL（比如 libssl.dll 缺失）。这种时候，连错误都还没来得及抛，进程就结束了。
