答案是用mysqld --console强制输出启动日志定位初始化卡点。该错误本质是mysqld在Windows服务模式下未完成初始化即退出，需检查my.ini路径/编码、basedir/datadir权限、废弃参数及InnoDB表空间状态。
直接用 mysqld --console 看终端输出，别等服务启动失败再翻日志——1067 错误根本不是 MySQL 崩溃了，而是它连初始化都没完成就被 Windows 杀掉，mysqld.err 很可能压根没生成。
用 mysqld --console 强制暴露真实错误
这是所有排查的前提，跳过这步等于蒙眼修车：
- 以管理员身份打开 CMD 或 PowerShell，
cd进 MySQL 的bin目录（如D:\mysql\bin） - 执行：
mysqld --defaults-file="D:/mysql/my.ini" --console（路径必须用正斜杠/，且确保my.ini存在） - 如果立即退出，第一行就是致命原因，比如：
Can't find messagefile 'D:/mysql/share/errmsg.sys'（basedir错）、InnoDB: Unable to open the first datafile（datadir无权限或路径不存在）、Unknown variable 'skip-federated'（用了已废弃参数） - 如果卡住不动，说明进程在后台等待（比如端口被占、InnoDB 恢复卡住），此时 Ctrl+C 中断后改用
netstat -ano | findstr :3306查端口
重点检查 my.ini 里这三类硬伤
80% 的 1067 都栽在这几处，而且不报具体行号：
-
basedir和datadir路径含空格或中文时，必须用双引号包裹；但更稳妥的是迁移到纯英文无空格路径（如D:/mysql），避免引号解析失效 - 文件编码必须是 ANSI 或 UTF-8 无 BOM；用记事本另存为选“ANSI”，Notepad++ 里确认编码不是 UTF-8-BOM
- MySQL 5.7+ 已移除的参数会直接导致启动失败：
skip-innodb、innodb_additional_mem_pool_size、query_cache_type、default-storage-engin（拼错）等，删掉或注释掉 -
log-error指向的目录必须可写，否则连错误日志都打不开，形成死循环
验证 datadir 权限和服务账户访问能力
Windows 下权限问题最隐蔽，LocalSystem 并非万能：
直播间话术巡检-windows
下载
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
- 右键
datadir文件夹（如D:\mysql\data）→「属性」→「安全」→ 确认服务运行账户（默认是LocalSystem，或你手动指定的用户）有「完全控制」权限 - 别依赖「继承自父项」——手动点「编辑」，勾选「修改」「写入」「列出文件夹内容」
- 如果改过服务账户（比如设成某个域用户），该账户必须能访问
basedir和datadir下所有子目录；NTFS 权限不跨卷，网络路径基本不可用 -
ib_logfile0和ib_logfile1损坏也会静默失败，可临时重命名这两个文件再试
别忽略服务注册命令本身是否合法
很多人注册服务时就埋下雷：
- 注册命令必须是：
mysqld --install MySQL80 --defaults-file="D:/mysql/my.ini"（不含--console） - 错误示例：
mysqld --install MySQL80 --console --defaults-file="D:/mysql/my.ini"——--console仅用于调试，服务模式下会导致加载冲突并直接 1067 - 如果之前注册错了，先用
mysqld --remove MySQL80卸载，再重新注册 - 注册后不要立刻
net start mysql，先跑一遍mysqld --console确认能稳定输出到终端
真正棘手的情况是：终端只打印 Aborting 就退出，连模块名都没来得及打出——这时候往往卡在 InnoDB 表空间校验、插件加载失败，或者 my.ini 里某一行末尾多了一个不可见的空格或制表符。
