📄 一句话概括
人的威胁分无心（误操作、误删库）与有意（内部窃密、恶意破坏）——对策两手：流程管无心，权限管有意。
📝 本节和前面几节的关系
三类威胁收官：物理（7-1）、技术（7-2）之后是人——统计上人是最常见的故障来源（「手滑删库」的新闻每年都有）。它的对策正好是第六章成果的验收：权限（6-4）、备份（6-6）、监控（6-5）在这里全部派上用场。
一、无心之失（占大头）
| 威胁 | 对策 |
|---|---|
DELETE 忘 WHERE（3-12 的教训） |
权限分级＋操作前备份＋测试环境先跑 |
| 误删表/误删库 | 生产环境禁用 DROP 权限、备份在手 |
| 改错配置 | 配置版本管理、变更双人复核 |
| 发错环境（测试脚本跑生产） | 环境_HARD 标记、生产只读默认 |
二、有意之为（防内鬼）
| 威胁 | 对策 |
|---|---|
| 内部人员窃取数据 | 最小权限（6-4）＋操作审计（6-5） |
| 离职员工账号未清 | 离职当天 REVOKE（6-4 的僵尸账号） |
| 恶意破坏 | 权限最小化＋日志回放追责 |
三、流程管无心，权限管有意
- 无心的核心对策是流程：高危操作四步——先备份、测试跑、双人看、留记录
- 有意的核心对策是权限＋审计：他做不到（权限小）＋做了必留痕（日志）
- 两者合力的底线：人的错误可以发生，但不可以致命——这正是 1-4「恢复」优势的最终含义
四、动手 Demo：给「手滑」上三道锁
-- 场景：运营同学要删一条脏数据
-- 第 1 锁（权限）：运营账号只给了 SELECT+UPDATE，没给 DELETE
-- → DELETE 直接被拒：ERROR 1142
-- 第 2 锁（备份）：真要删？先备份目标行
CREATE TABLE books_backup AS SELECT * FROM books WHERE id = 9;
DELETE FROM books WHERE id = 9; -- 这次有 WHERE，且行已备份
-- 第 3 锁（审计）：操作留痕
INSERT INTO audit_log (who, action, at)
VALUES ('运营', 'DELETE books id=9 (已备份)', datetime('now'));
【准备块】3-15 前的 students 库或 5-19 的 book_review 库均可；重点体会三道锁的顺序。
五、30 秒实验
想想你有没有过「Shift+Delete 手滑删文件」——没有回收站兜底的删除有多可怕。数据库没有回收站，备份就是它的回收站；权限就是「把回收站钥匙别在少数人腰上」。
六、常见误区
- 「内部员工都是可信的」：信任要靠制度兑现——权限与审计不是不信任，是保护双方
- 「误操作靠培训就能防住」：培训有用但不够，流程与权限才是硬约束（人一定会累、一定会手滑）
- 「出了事先追责」：先恢复（还原备份）、后复盘——恢复永远排在追责前面
自测三问
1. 人的威胁两手对策？（流程管无心：备份/测试/复核；权限管有意：最小权限＋审计） 2. 高危操作四步？（先备份、测试跑、双人看、留记录） 3. 出事故后的第一动作？（先恢复业务，再复盘追责）- ☐ 下一节（7-4 错误日志-发生错误的历史记录）
相关笔记
- 用户、权限-根据用户更改允许访问的范围 —— 「权限管有意」的机制出处
- DELETE-删除记录 —— 忘 WHERE 全表遭殃：无心之失的教科书案例
- 错误日志-发生错误的历史记录 —— 下一节：错误发生后先看哪里
- 🗄️ 数据库基础 · 索引 —— 全课路线图