直接说结论：90%以上的情况，问题不出在MySQL本身，而是my.ini配置文件的编码、路径写法或目录权限出了问题。Windows服务管理器只报“错误1067：进程意外终止”，但根本不会告诉你哪一行错了——得绕过它，用命令行+人工校验才能定位。
为什么mysqld --console比服务管理器有用
Windows服务启动有超时限制（通常30秒），一旦mysqld.exe在初始化阶段崩溃，服务管理器就直接杀掉进程并报1067，不写日志、不提示原因。而mysqld --console会把所有错误原样打到命令行窗口，是唯一能看见真实报错的方式。
操作步骤：
- 以管理员身份打开CMD或PowerShell
-
cd进入MySQL的bin目录（如C:mysqlin） - 执行：
mysqld --defaults-file="C:mysqlmy.ini" --console
此时窗口里如果立刻退出，说明配置文件有致命错误；如果卡住几秒后报错，就照着错误信息逐条修。常见输出如：[ERROR] [MY-010119] [Server] Aborting后面紧跟着具体原因。
my.ini必须是ANSI编码，不是UTF-8
MySQL 5.7/8.0的Windows版mysqld.exe完全不支持UTF-8编码的配置文件。哪怕只加了一行中文注释# 数据目录，只要文件存成UTF-8（含BOM或无BOM），就会静默崩溃，报1067。
验证和修复方法：
- 用PowerShell检查：
Get-Content my.ini -Encoding Byte | Select -First 5—— 如果开头三字节是EF BB BF，就是UTF-8-BOM - 用记事本打开
my.ini→「另存为」→ 编码选ANSI（不是UTF-8，不是Unicode）→ 覆盖保存 - VS Code / Notepad++ 默认保存为UTF-8，不能直接点“保存”，必须手动切换编码再存
注意：改完后别急着重启服务，先用--console再试一次。
路径里的反斜杠必须双写或改用正斜杠
Windows下my.ini中所有路径（basedir、datadir、log-error）如果只写单个，会被mysqld当作转义符解析，导致路径乱码、目录找不到，直接1067崩溃。
错误示例：datadir=C:mysqldata → m被当成转义，实际路径变成非法字符
Windows 桌面自动化技能，支持鼠标控制（移动/点击/拖拽/滚轮/截图）、键盘输入（文字输入/按键/组合键）、窗口管理（查找/聚焦/最大化/最小化/关闭/移动）、截图并发送文件。提供两种截图方式：Python pyautogui 截图（集成在自动化流程中）和 PowerShell + .NET 零依赖截图（支持区域截图和多显示器）。当用户需要自动化 Windows 桌面操作、控制鼠标键盘、管理窗口、执行 GUI 自动化任务、截图发送文件时使用。
正确写法（任选其一）：
-
datadir=C:\mysql\data（双反斜杠） -
datadir=C:/mysql/data（正斜杠，更推荐，跨平台且不会误转义）
额外注意：log-error指向的完整目录（如C:/mysql/logs/）必须手动创建好，mysqld不会自动建目录，缺了就崩。
端口没被占，但ICS服务在偷偷抢
有些情况netstat -ano | findstr :3306查不到占用者，MySQL日志里却反复出现Can't start server: Bind on TCP/IP port——这很可能是Windows自带的Internet Connection Sharing (ICS)服务在作祟。
ICS会动态预留一批端口（包括3306），但它不走常规socket监听，所以netstat看不见，事件查看器里也找不到明确提示。
临时验证方法：
- Win+R输入
services.msc，找到Internet Connection Sharing (ICS) - 右键→停止服务
- 再试
mysqld --console
如果这时能正常启动，就确认是ICS冲突。长期方案是禁用ICS，或把MySQL端口改成3307并在my.ini里显式声明：port=3307。
最常被忽略的一点：datadir目录必须由mysqld --initialize生成，不能手动复制旧数据，也不能留空。哪怕路径全对、编码正确、端口空闲，如果datadir里没有ibdata1、mysql系统库等初始文件，mysqld一样会崩溃退出，且错误信息极短——只有[ERROR] [MY-010119] [Server] Aborting这一行。
