systemctl status mysql仅显示进程状态，不能确认数据库是否可用；需结合mysqladmin ping、端口监听检查、show full processlist及threads_connected/threads_running等指标综合判断。
systemctl status mysql 能看到服务是否在跑，但看不出数据库有没有响应
Linux 下 systemctl status mysql 或 systemctl status mysqld 只能告诉你进程是不是活着，active (running) 不代表 MySQL 能处理请求。比如端口被防火墙拦了、max_connections 耗尽、或 mysqld 卡在崩溃恢复中，这时服务状态仍是 active，但客户端连不上。
真正要确认“数据库在线且可用”，得组合验证：
-
mysqladmin -u root -p ping—— 返回mysqld is alive才算通过基础连通性测试 -
netstat -tulnp | grep :3306或ss -tulnp | grep :3306—— 确认 3306（或自定义端口）确实在 LISTEN -
ps aux | grep mysqld—— 排除僵尸进程假象（比如主进程已死，只剩子线程残留）
show processlist 显示不全，容易漏掉关键长事务
SHOW PROCESSLIST 默认只返回前 100 条，而慢查询、锁等待、大事务往往排在后面甚至被截断。尤其在连接数多、并发高的场景下，SHOW PROCESSLIST 几乎没用。
必须用：SHOW FULL PROCESSLIST —— 这个命令不截断，能看清完整 SQL 和真实 Time 值。
更精准的过滤方式是直接查系统表：
-
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 60 ORDER BY TIME DESC;—— 找出执行超 60 秒的活跃查询 -
SELECT * FROM information_schema.PROCESSLIST WHERE STATE = 'Locked' OR STATE LIKE '%copy%';—— 锁表或拷表操作通常卡在这里
注意：SHOW PROCESSLIST 本身会加读锁，高峰期频繁执行可能拖慢性能，别当监控轮询用。
show status 里 Connections 和 Threads_connected 完全是两回事
新手常把 Connections 当成“当前连接数”，其实它是自启动以来所有连接尝试的累计值（包括失败和已断开的），毫无实时负载参考价值。
真正该盯的两个指标是：
-
Threads_connected：当前已建立但未必活跃的连接总数，接近max_connections就要预警（新连接会被拒绝） -
Threads_running：此刻正在执行 SQL 的线程数，持续 > 5–10 表明有慢查询堆积或锁竞争，是 CPU/IO 压力的直接信号
查法：
SHOW STATUS LIKE 'Threads_connected';SHOW STATUS LIKE 'Threads_running';SHOW VARIABLES LIKE 'max_connections';
Uptime 和 error.log 才是判断“真稳定”的硬指标
SHOW STATUS LIKE 'Uptime'; 返回的是秒数，如果只有几秒或几百秒，说明刚重启过——这时候看其他指标意义不大，得先查日志。
错误日志路径不是固定的，优先查变量：
-
SHOW VARIABLES LIKE 'log_error';—— 大多数 Linux 是/var/log/mysql/error.log或/var/log/mysqld.log，Ubuntu 常见于/var/log/mysql/error.log
重点扫这些关键词：
-
Aborted_connects持续上涨 → 密码错、host 不符、max_connect_errors触发锁定、防火墙拦截 -
InnoDB: Starting crash recovery→ 上次非正常关闭，恢复中可能卡住 -
Out of memory或Tablespace is full→ 磁盘或内存资源告急
别只盯着 “MySQL started successfully” 这类正常日志，真正的问题藏在 Warning 和 Error 行里，而且往往出现在 Uptime 很短的时候。
