优先用 SELECT @@version 获取 MySQL 版本，它更轻量、执行快且兼容严格 SQL 模式；SELECT VERSION() 返回含编译信息的完整字符串，适合调试和确认后端真实版本。
查 MySQL 版本：用 SELECT VERSION() 还是 SELECT @@version？
两者都能拿到版本号，但行为有差异。SELECT VERSION() 是标准 SQL 函数，返回带编译信息的完整字符串（比如 8.0.33-0ubuntu0.22.04.2）；SELECT @@version 读系统变量，更轻量，值一样但不带额外后缀。生产环境建议优先用 @@version，尤其在监控脚本里——它不走函数解析路径，执行更快，也避开了某些严格 SQL 模式下对函数调用的限制。
常见错误：有人写 SELECT VERSION（漏了括号），MySQL 会报错 ERROR 1064 (42000)，因为这被当成字段名而非函数调用。
- 开发调试时用
SELECT VERSION()更直观，含平台和编译信息 - 自动化采集（如 Prometheus exporter）用
SELECT @@version更稳定 - 如果连接的是 ProxySQL 或中间件，
@@version可能返回代理版本，此时必须用SELECT VERSION()确认后端真实版本
看运行状态：SHOW STATUS 的关键指标有哪些？
SHOW STATUS 返回几百个计数器，但日常排查只盯几个：Threads_connected、Threads_running、Queries、Slow_queries、Uptime。它们不是实时快照，而是自实例启动以来的累计值或当前瞬时值，所以得结合时间维度看趋势，不能单看一个数字下结论。
容易踩的坑：直接执行 SHOW STATUS 会输出全部变量，终端刷屏且难定位。别硬翻，加 LIKE 过滤：
SHOW STATUS LIKE 'Threads%';
或者用更精准的正则匹配（MySQL 8.0+）：
SHOW STATUS WHERE Variable_name REGEXP '^Threads|Slow|Uptime$';
-
Threads_connected高但Threads_running低 → 大量空闲连接，检查应用是否没正确释放连接 -
Slow_queries持续上涨 → 立刻查slow_query_log是否开启，并确认long_query_time设置是否合理（默认 10 秒，线上通常要设成 1 或 0.5） -
Uptime很小（比如才几百秒）→ 实例刚重启过，历史计数器不可信，需等稳态后再采样
替代方案：为什么有时 mysqladmin 比 SQL 更快？
当 MySQL 响应慢或连接卡住时，SELECT @@version 或 SHOW STATUS 可能 hang 住，因为它们走 SQL 执行引擎。而 mysqladmin 是客户端工具，直连 server 状态端口，绕过查询解析层，成功率更高。
常用命令：
mysqladmin -u root -p version
mysqladmin -u root -p extended-status | grep -E "Threads_connected|Slow_queries"
- 权限要求更低：
mysqladmin version只需要CONNECTION_ADMIN（旧版是SUPER），而SHOW STATUS在某些安全模式下会被限制 - 无法登录 MySQL 时，
mysqladmin ping是判断服务是否存活最轻量的方式 - 注意：
mysqladmin输出格式不统一，脚本解析时要用-s（silent）模式避免列头干扰
版本与状态数据的可靠性边界在哪？
VERSION() 和 SHOW STATUS 都依赖 server 正常响应。一旦发生严重锁表、复制延迟卡死、或 InnoDB buffer pool 崩溃，这些命令本身可能失败或返回陈旧数据。比如 SHOW STATUS 中的 Questions 计数，在 crash recovery 后不会重置，但 Uptime 会归零——这种不一致性就是信号。
真正关键的状态不在 SQL 层，而在 OS 层：ps aux | grep mysqld 看进程是否存在，netstat -tlnp | grep :3306 看端口是否监听，tail -n 20 /var/log/mysql/error.log 看最近错误。SQL 命令只是辅助，不是真相本身。
