MySQL启动失败报错1067是Windows服务管理器提示“进程意外终止”，根本原因需查错误日志、端口占用、datadir路径、配置语法及插件加载等。
MySQL服务启动失败，报错1067：进程意外终止
错误1067不是MySQL自身的SQL错误码，而是Windows服务管理器返回的通用错误——“进程意外终止”。它不说明具体原因，只表示mysqld.exe在尝试作为Windows服务启动时，几秒内就退出了。真正的问题藏在日志里，或由配置、权限、端口、数据目录状态等引发。
检查MySQL错误日志是第一步，不是可选项
MySQL在启动失败时，通常会把关键线索写入错误日志（error.log），但很多人没意识到：这个文件的位置取决于my.ini中log-error的设置，而不是默认在data/目录下。如果log-error路径不可写，甚至日志都写不进去，那就更难定位。
- 先确认
my.ini（或my.cnf）中是否有log-error=D:/mysql/logs/error.log这类明确配置 - 检查该路径是否存在、MySQL服务账户（通常是
SYSTEM或自定义用户）是否有写入权限 - 若没配
log-error，MySQL可能退回到hostname.err，位于datadir目录下；此时需确保datadir路径存在且可读写 - 临时方案：命令行手动运行
mysqld --console，错误会直接打印到终端，绕过服务封装，最快速暴露问题
常见直接诱因与对应检查项
1067背后高频原因有限，按优先级逐项排除比盲目重装高效得多：
-
端口被占用：检查
port=3306是否被其他程序（如另一个MySQL实例、Skype、Docker）占用，用netstat -ano | findstr :3306确认 -
datadir指向错误或损坏：确认
datadir路径真实存在，且包含ibdata1、mysql/子目录等必要文件；若最近移动过数据目录，my.ini中路径必须同步更新并反斜杠转义（如D:\\mysql\\data） -
配置语法错误：哪怕多一个空格、少一个等号，
mysqld也会静默退出。用mysqld --defaults-file="C:/my.ini" --validate-config验证配置有效性 -
插件加载失败：如启用了
plugin-load-add但对应DLL不存在，或secure-file-priv指向了不存在的路径，都会导致启动中断
重装或初始化前务必确认是否真需要初始化
看到“无法启动”，不少人直接删data/、跑mysqld --initialize。但这是有损操作：原库表结构和数据全丢。只有在确认datadir已损坏（如ib_logfile0缺失、mysql.user表崩溃）且无备份时才走这步。更安全的做法是：
- 先尝试用
mysqld --skip-grant-tables --shared-memory跳过权限系统启动，看能否进入 - 若能，导出关键库：
mysqldump -u root --all-databases > backup.sql - 再执行
mysqld --initialize-insecure --datadir="D:/mysql/data"（注意--initialize-insecure生成空密码root，比--initialize更易后续登录）
真正卡住的，往往是my.ini里一个拼错的路径，或Windows服务注册时残留的旧参数。盯着错误日志，比反复重启服务有用得多。
