📄 一句话概括
监控＝给数据库装仪表盘：操作历史（谁干了什么）、日志（系统说了什么）、资源（还剩多少家底）——三样合起来，故障才有得查、异常才有得抓。
📝 本节和前面几节的关系
6-4 管「准不准入」，本节管「进来之后干了什么、系统状态如何」。它与 6-9（版本升级）是运维的两大日常：一个盯现在，一个防将来。
一、三样仪表
| 仪表 | 记什么 | 用来干什么 |
|---|---|---|
| 操作历史/审计 | 谁在几点执行了哪条 SQL | 追责、排错、发现异常查询 |
| 错误/慢查询日志 | 报错、超时的语句 | 定位性能瓶颈与故障 |
| 资源监控 | CPU、内存、磁盘、连接数 | 提前发现容量告急 |
二、为什么必须有日志
- 出了事能回放：半夜数据被改了——审计日志告诉你是谁、几点、哪条语句
- 慢查询是性能侦探：一条
SELECT *忘加WHERE，日志里一眼可见 - 异常模式识别：凌晨三点一个账号突然高频登录失败——有人在爆破（6-4 的口令防线正在被试探）
三、资源监控的红线思维
给每项资源设警戒线，接近就报警，而不是等满了才慌：
- 磁盘 80% → 该清理/扩容了（磁盘写满是数据库猝死的头号原因）
- 连接数接近上限 → 可能有连接泄漏（没关的连接，第三章
close()意识的数据库版）
四、动手 Demo：三份「日志」的最小体验
SQLite 本身不带审计功能，但我们可以亲手攒一份「人肉审计日志」：
-- ① 建审计表
CREATE TABLE audit_log (
id INTEGER PRIMARY KEY,
who TEXT, -- 操作人
action TEXT, -- 干了什么
at TEXT -- 几点
);
-- ② 关键操作后手动补一条（应用层本该自动做）
INSERT INTO books VALUES (1, '数据库入门');
INSERT INTO audit_log (who, action, at)
VALUES ('admin', 'INSERT INTO books id=1', datetime('now'));
-- ③ 查「谁动过数据」
SELECT * FROM audit_log ORDER BY at DESC;
【准备块】在线 SQLite 运行器即可重放，无外部依赖。
五、30 秒实验
打开手机的电池用量页：每个 App 耗电多少、后台活动几小时——这就是「资源监控」的用户版。问：如果数据库是手机，它的「耗电排行」该看什么？（连接数、慢查询、磁盘增速。）
六、常见误区
- 「日志存着就行」：没被看过的日志＝没写；要配告警，异常主动找你
- 「日志想存多久存多久」：日志本身吃磁盘，要定保留期限与轮转（旧日志归档删除）
- 「监控只是运维的事」：写 SQL 的人不看慢查询日志，等于蒙眼开车
自测三问
1. 操作历史、错误日志、资源监控各解决什么问题？（回放追责／定位故障瓶颈／提前发现容量告急） 2. 磁盘写满对数据库意味着什么？（大概率猝死——写不进任何数据，故设 80% 警戒线） 3. SQLite 有没有内置用户审计？（没有——审计通常由应用层或更大型 DBMS 提供，本节 Demo 是人肉版）- ☐ 下一节（6-6 备份、全量备份、差分备份、增量备份-定期记录当前的数据）
相关笔记
- 用户、权限-根据用户更改允许访问的范围 —— 上一节：准入控制，本节是行为监控
- 备份、全量备份、差分备份、增量备份-定期记录当前的数据 —— 下一节：监控发现问题，备份保住退路
- WHERE、=、AND、OR-缩小范围查找符合条件的记录 —— 忘加 WHERE 的慢查询正是日志要抓的典型
- 🗄️ 数据库基础 · 索引 —— 全课路线图