MySQL服务是否正常运行，直接关系到数据库能否被应用访问。最直接有效的验证方式是结合系统级检查和数据库级连通性测试。
查看MySQL进程是否存在
在Linux或macOS系统中，可通过进程命令确认mysqld是否在后台运行：
执行 ps aux | grep mysqld，若看到类似 mysqld --daemonize 或 /usr/sbin/mysqld 的进程，说明服务已启动 若只看到 grep mysqld 本身而无实际进程，代表MySQL未运行 部分系统使用systemd管理，可运行 systemctl is-active mysql（或 mariadb，取决于安装版本），返回 active 表示运行中检查MySQL监听端口是否就绪
MySQL默认监听3306端口，端口状态能反映服务是否完成初始化并开始接受连接：
用 netstat -tuln | grep :3306 或 ss -tuln | grep :3306 查看是否有 LISTEN 状态的条目 若端口未监听，可能是配置文件中 bind-address 设置为127.0.0.1但本地未启用，或服务异常退出 Windows用户可用 netstat -ano | findstr :3306 替代尝试本地登录验证功能可用性
进程和端口都正常，还需确认MySQL实例能响应SQL请求：
运行 mysql -u root -p（或指定其他有权限用户），输入密码后进入 mysql> 提示符即表示服务可交互 进入后执行 SELECT VERSION(); 和 SHOW STATUS LIKE 'Uptime';，确认基础功能与运行时长正常 若提示 Access denied，说明服务在运行但认证失败；若提示 Can't connect to local MySQL server，则大概率是服务未启动或socket路径错误查看错误日志定位异常原因
当上述检查出现异常，错误日志是最权威的诊断依据：
日志路径通常在 /var/log/mysql/error.log、/var/log/mysqld.log 或MySQL数据目录下的 hostname.err 重点关注最近几分钟内带 [ERROR] 或 [FATAL] 的行，常见问题包括磁盘满、配置语法错误、表空间损坏等 启动失败时，日志末尾往往有明确的终止原因，例如 Could not open required defaults file 或 InnoDB initialization failure不复杂但容易忽略的是：有时MySQL进程存在，端口也监听，但因max_connections耗尽或账户被锁，导致新连接被拒绝。此时需结合登录测试与状态查询综合判断。
