案例：执行第一条命令，读懂健康检查输出¶
场景背景¶
- 角色：后端开发工程师，刚安装完 dbskiter
- 目标：执行第一条命令，理解每个指标的含义
- 前置：已完成安装和配置（见 01-安装与配置）
- 数据库：MySQL 8.0.32，业务库
jump
生活化比喻：数据库健康检查就像体检报告。每个指标对应一项身体检查：血压（连接数）、血糖（命中率）、心电图（锁等待）。本案例带你逐条读懂"体检报告"。
执行命令¶
dbskiter --database=jump monitor health
如果你配置了
default数据库，也可以直接：dbskiter monitor health
输出解读¶
第一部分：健康评分总览¶
============================================================
数据库健康检查: jump
============================================================
数据采集时间: 2026-06-18 14:30:22
数据库版本: MySQL 8.0.32
健康评分: 66.4 / 100
严重问题: 1
高风险问题: 3
中风险问题: 2
低风险问题: 4
解读：
| 项目 | 数值 | 含义 | 行动建议 |
|---|---|---|---|
| 健康评分 | 66.4 | 满分 100，"需要关注"级别 | 优先处理严重和高风险问题 |
| 严重问题 | 1 | 可能影响业务可用性 | 当天必须处理 |
| 高风险 | 3 | 可能导致性能或安全问题 | 本周内处理 |
| 中风险 | 2 | 需要优化但暂时不影响 | 本月安排 |
| 低风险 | 4 | 建议改进 | 有空再处理 |
评分标准：90-100 优秀，70-89 良好，<70 需要关注。66.4 分不算差，但有几个问题需要优化。
第二部分：性能指标（核心关注）¶
性能指标:
[绿色] 连接数使用率: 2.6% (4/151) 正常
[绿色] 缓冲池命中率: 99.90% 优秀
[绿色] 线程缓存命中率: 99.61% 正常
[绿色] 表缓存命中率: 90.65% 正常
[黄色] 临时表磁盘使用率: 61.96% 警告
[黄色] 行锁等待次数: 147 警告
[黄色] 排序合并次数: 5753 警告
逐条解读：
1. 连接数使用率：2.6%（正常）¶
当前连接: 4 个
最大连接数: 151
使用率: 2.6%
- 正常范围：< 70% 正常，70-85% 警告，> 85% 危险
- 含义：就像餐厅座位，4 个客人坐了 151 个座位中的 4 个，非常宽松
- 如果你看到 80%：说明业务并发高，或连接池配置过大，或连接未释放
- 相关命令：
dbskiter diagnose connections
2. 缓冲池命中率：99.90%（优秀）¶
缓冲池命中率: 99.90%
物理读: 123 次
逻辑读: 123,456 次
- 正常范围：> 95% 优秀，90-95% 良好，< 90% 需要优化
- 含义：InnoDB 缓存了常用数据，99.9% 的请求直接从内存读取，不需要读磁盘
- 就像：把常看的书放在桌面上（缓存），99.9% 不用去书架（磁盘）拿
- 如果你看到 85%：说明缓存不够大，需要增加
innodb_buffer_pool_size - 相关命令：
dbskiter diagnose realtime
3. 临时表磁盘使用率：61.96%（警告）¶
内存临时表: 15,234 个
磁盘临时表: 24,891 个
磁盘使用率: 61.96%
- 正常范围：< 20% 正常，20-50% 警告，> 50% 严重
- 含义：MySQL 处理复杂查询时，内存放不下临时结果，61.96% 落到磁盘
- 原因：查询用了
GROUP BY、ORDER BY、DISTINCT，或包含 BLOB/TEXT 字段 - 就像：算一道复杂数学题，草稿纸（内存）写不下，只能写到笔记本（磁盘），慢很多
- 优化方向：
- 优化 SQL，避免大字段排序
- 增加
tmp_table_size和max_heap_table_size - 相关命令：
dbskiter diagnose slow-queries
4. 行锁等待次数：147（警告）¶
行锁等待次数: 147
行锁等待平均时间: 0.05s
- 正常范围：0 优秀，< 50 正常，50-200 警告，> 200 严重
- 含义：有 147 次事务因为想修改的行被其他事务锁住了，被迫等待
- 就像：两个人都想修改同一个 Excel 单元格，一个正在改，另一个只能等
- 优化方向：
- 减少事务粒度（事务越小越好）
- 优化热点数据访问（如库存扣减）
- 相关命令：
dbskiter lock analyze
5. 排序合并次数：5753（警告）¶
排序合并次数: 5753
内存排序: 45,231 次
磁盘排序: 5,753 次
- 正常范围：0 优秀，< 1000 正常，1000-5000 警告，> 5000 严重
- 含义：ORDER BY 或 GROUP BY 时，内存排序缓冲区不够，5,753 次需要合并多次排序结果
- 优化方向：
- 增加
sort_buffer_size - 优化索引，让 ORDER BY 走索引排序（避免 filesort）
- 相关命令：
dbskiter audit sql分析具体 SQL
第三部分：配置检查¶
配置检查:
[绿色] 配置检查: 18 项通过
[黄色] 慢查询阈值: 10.0s 警告
[绿色] 查询缓存: 已关闭（MySQL 8.0 默认行为）
[绿色] 表缓存: 2000
重点解读：
慢查询阈值：10.0s（警告）¶
long_query_time: 10.0s
建议: 生产环境建议设置为 1-2s
- 含义：执行时间超过 10 秒的查询才记录到慢查询日志
- 问题：10 秒太慢了！用户 3 秒就 timeout 了，你 10 秒才记录，根本抓不到问题
- 建议：生产环境设为 1-2 秒，测试环境 0.5-1 秒
- 如何修改：
SET GLOBAL long_query_time = 1.0;
第四部分：安全检查¶
安全状态:
[绿色] 空用户名检查: 0 个
[绿色] 无密码用户检查: 0 个
[绿色] 匿名用户检查: 0 个
[绿色] test 数据库检查: 0 个
[绿色] SSL 连接: 已启用
[黄色] SUPER 权限用户: 4 个
[黄色] 远程 root 访问: 1 个
重点解读：
SUPER 权限用户：4 个（警告）¶
- 含义：4 个用户拥有 SUPER 权限，可以修改数据库配置、杀掉其他用户连接
- 风险：权限过大，误操作可能导致数据库配置被改
- 建议：SUPER 权限只给 DBA，应用账号、监控账号、备份账号都不需要 SUPER
- 相关命令：
dbskiter security permissions
远程 root 访问：1 个（警告）¶
- 含义：有一个
root@%账号，可以从任何 IP 连接 - 风险：root 权限最高，一旦被破解，整个数据库暴露
- 建议：删除
root@%，只允许root@localhost或特定 IP - 修复：
DROP USER 'root'@'%';
第五部分：容量信息¶
容量信息:
[绿色] 数据库大小: 0.03 GB
[绿色] 表数量: 507
[绿色] 磁盘空间: 充足
- 含义：数据库很小，只有 0.03 GB（30 MB），507 张表
- 注意：数据库大小 ≠ 磁盘总占用。磁盘上还有 binlog、备份、日志等
- 预测容量：
dbskiter monitor capacity-advanced --resource=disk
后续行动清单¶
根据本次健康检查，你需要做以下事情：
| 优先级 | 问题 | 行动 | 命令 |
|---|---|---|---|
| P0-今天 | 远程 root 访问 | 删除 root@% |
dbskiter security audit 后按建议修复 |
| P0-今天 | SUPER 权限用户 4 个 | 审查权限，回收不必要的 SUPER | dbskiter security permissions |
| P1-本周 | 慢查询阈值 10s | 改为 1-2s | SET GLOBAL long_query_time = 1.0 |
| P1-本周 | 临时表磁盘使用率 61.96% | 抓慢查询，优化 SQL | dbskiter diagnose slow-queries |
| P1-本周 | 行锁等待 147 次 | 锁分析，优化事务 | dbskiter lock analyze |
| P2-本月 | 排序合并 5753 次 | 优化索引或调大 sort_buffer | dbskiter audit recommend-indexes |
| P3-有空 | 10 张表旧版 UTF8 | 迁移到 utf8mb4 | 低峰期 ALTER TABLE |
常见疑问¶
Q1：健康评分 66.4 是不是很低？数据库要崩了？¶
答：不是。66.4 是"需要关注"，不是"要崩了"。当前连接数 2.6%、缓冲池命中率 99.9%，数据库运行很健康。扣分主要来自：配置问题（慢查询阈值）、权限问题（SUPER 用户、远程 root）、性能优化建议（临时表、锁等待）。当天修完权限问题，分数就能到 75+。
Q2：这些黄色警告必须修吗？不修会怎样？¶
答：分情况： - 权限类（SUPER、远程 root）：必须修，安全风险 - 配置类（慢查询阈值）：建议修，否则抓不到慢 SQL - 性能类（临时表、锁等待）：业务不忙可以不修，但高峰期可能出问题
Q3：绿色指标是不是可以不管了？¶
答：绿色是"正常"，但建议定期看趋势。比如今天连接数 2.6% 是绿色，如果下周变成 60% 就是警告了。可以用基线对比：
dbskiter --database=jump inspector baseline --create # 今天建立基线
# 下周对比
dbskiter --database=jump inspector baseline --compare
Q4：健康检查多久跑一次？¶
答： - 生产核心库：每天一次（可以写 cron 定时） - 业务库：每周一次 - 测试库：每月一次或按需
# 加入 crontab（每天凌晨 2 点执行）
0 2 * * * dbskiter --database=jump monitor health >> /var/log/dbskiter/health.log 2>&1
下一步学习¶
| 你想深入学习... | 推荐案例 |
|---|---|
| 抓慢查询，优化 SQL | 业务卡顿查慢查询 |
| 分析锁等待 | 接口超时查锁等待 |
| 安全整改 | 安全审计排查 |
| 容量预测 | 预判磁盘爆满 |
命令速查¶
# 健康检查（最常用）
dbskiter monitor health
# 实时诊断（看当前谁在跑）
dbskiter diagnose realtime
# 慢查询分析
dbskiter diagnose slow-queries
# 锁分析
dbskiter lock analyze
# 安全审计
dbskiter security audit
# 容量预测
dbskiter monitor capacity-advanced --resource=disk
# 建立基线（长期对比）
dbskiter inspector baseline --create