MySQL服务真正运行需四步验证：一查mysqld主进程是否存在；二查3306端口是否LISTEN且PID匹配；三查error.log末尾是否有“mysqld: ready for connections”；四登录后执行SELECT VERSION()和SHOW STATUS LIKE 'Uptime'确认Uptime>0。

服务进程是否真实存在

只靠 mysql -u root -p 能连上，不代表 MySQL 服务真在运行——它可能只是 socket 文件残留或客户端假连接。真正要确认的是 mysqld 进程是否活着。

Windows 下执行：
tasklist /fi "imagename eq mysqld.exe"
Linux/macOS 下执行：
ps -ef | grep mysqld | grep -v grep

• 必须看到 mysqld 主进程（不是 mysqld_safe 或临时脚本）
• 若输出为空，说明服务根本没启动，mysql 客户端连的可能是旧实例、Docker 容器，甚至本地 socket 文件残留
• Windows 上注意：服务名未必是 MySQL，可能是 MySQL80 或自定义名，得配合 sc query 确认

端口监听是否实际生效

MySQL 启动后默认监听 3306，但“启动成功”不等于“端口就绪”。很多情况服务看似启动了，却卡在初始化阶段，端口根本没 bind。

检查命令：
Windows：netstat -ano | findstr :3306
Linux/macOS：ss -tuln | grep :3306 或 lsof -i :3306

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 关键看状态是否为 LISTEN，且 PID 对应 mysqld 进程
• 如果返回空，但 ps 显示 mysqld 在跑，大概率是配置了 skip-networking=1 或绑定了 127.0.0.1 而非 0.0.0.0，需查 my.cnf 中的 bind-address
• 若提示 Permission denied（尤其 Linux），说明 systemd 启动时权限不足，常见于 /var/lib/mysql 目录属主不是 mysql 用户

错误日志里有没有致命报错

MySQL 启动失败时，往往不报错就静默退出。唯一可靠线索是 error log，不是控制台输出，也不是 Windows 事件查看器。

日志位置：
Windows：C:\ProgramData\MySQL\MySQL Server 8.0\Data\*.err
Linux：/var/log/mysql/error.log 或 /var/lib/mysql/hostname.err

• 重点搜 Aborting、Fatal error、Can't start server、binlog index entry not found
• 如果日志最后几行是 mysqld: ready for connections，才算真正就绪；若停在 Starting crash recovery 或反复 Shutdown complete，说明启动中途失败
• 宝塔用户注意：面板里“错误日志”按钮常打不开，直接 SSH 查 /www/server/data/*.err 更靠谱

连接后能否执行基础状态查询

能输入密码、进到 mysql> 提示符，还不够。有些安装会跳过权限表初始化，导致登录成功但无法操作。

登录后立刻执行：
SELECT VERSION();
SHOW STATUS LIKE 'Uptime';
SHOW VARIABLES LIKE 'basedir';

• Uptime 值必须大于 0（单位秒），否则说明刚连上就断了或处于半初始化状态
• basedir 输出路径必须与你安装路径一致，避免连错其他版本实例
• 如果 SHOW BINARY LOGS; 报错 ERROR 1381 (HY000)，说明 binlog 损坏，MySQL 8.0 会拒绝提供完整服务，需清理 mysql-bin.* 文件

真正卡住的点，往往不在“能不能连”，而在“连上了但服务没完全加载”。error log 里那句 ready for connections 是唯一可信信号，其余全是中间态。