答案是用mysqld --console强制输出启动日志定位初始化卡点。该错误本质是mysqld在Windows服务模式下未完成初始化即退出，需检查my.ini路径/编码、basedir/datadir权限、废弃参数及InnoDB表空间状态。
1067 错误不是 MySQL 崩溃，而是它根本没完成初始化就被 Windows 杀掉了——必须用 mysqld --console 看第一行输出，否则永远在猜。
用 mysqld --console 强制暴露真实错误
Windows 服务模式会吞掉所有早期启动日志，mysqld.err 往往压根没生成。跳过这步等于蒙眼修车。
- 以管理员身份打开 CMD 或 PowerShell，
cd进 MySQL 的bin目录（如D:\phpstudy_pro\Extensions\MySQL5.7.26\bin） - 执行：
mysqld --defaults-file="D:/phpstudy_pro/Extensions/MySQL5.7.26/my.ini" --console（路径必须用正斜杠/，且确保文件存在） - 如果立即退出，第一行就是致命原因：
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 并非万能：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 右键
datadir文件夹（如D:\phpstudy_pro\Extensions\MySQL5.7.26\data）→「属性」→「安全」→ 确认服务运行账户（默认是LocalSystem，或你手动指定的用户）有「完全控制」权限 - 别依赖「继承自父项」——手动点「编辑」，勾选「修改」「写入」「列出文件夹内容」
- 如果改过服务账户（比如设成某个域用户），该账户必须能访问
basedir和datadir，NTFS 权限不认“当前登录用户”
注意 ib_logfile* 和 ibdata1 的状态
InnoDB 初始化失败常表现为静默退出，mysqld --console 会明确报 InnoDB: Unable to open the first datafile：
- 若确定数据可丢（如本地开发环境），可临时重命名
ib_logfile0、ib_logfile1和ibdata1，再试启动 - 若需保留数据库，不要删
mysql/、performance_schema/等系统库目录，只处理 InnoDB 日志和共享表空间文件 - 全新安装但
datadir为空时，必须先执行mysqld --initialize-insecure --datadir="D:/mysql/data"，否则连mysql.user表都没有
真正棘手的情况是：命令行跑 mysqld --console 后只显示 Aborting 就退出，连模块名都没来得及打印——这时大概率是 my.ini 编码含 BOM、路径中存在不可见 Unicode 字符，或者 basedir 根本指向了一个空文件夹。
