📄 一句话概括
权限体系回答两个问题：你是谁（用户）、你被允许做什么（权限）——核心原则是最小权限：够用就好，多一点都不给。
📝 本节和前面几节的关系
6-2 说「别被坏」靠账号管理，本节把它变成可操作的体系。第一章 1-4 讲「控制、访问权限」是优势名词，本节开始动手真配；SQL 层面用 GRANT/REVOKE（SQLite 单机嵌入式没有这套用户系统，本节用 MySQL 语法演示）。
一、两个概念
- 用户（User）：登录数据库的身份。每个应用、每个人应该有自己的账号，绝不能全班共用一个 root
- 权限（Privilege）：允许的操作，常见三类——查询（SELECT）／修改（INSERT·UPDATE·DELETE）／结构（CREATE·DROP·ALTER）
二、GRANT 与 REVOKE
-- 建一个只能查书评的用户（MySQL 语法）
CREATE USER 'reader'@'%' IDENTIFIED BY '强口令';
GRANT SELECT ON book_review.* TO 'reader'@'%';
-- 收回权限
REVOKE SELECT ON book_review.* FROM 'reader'@'%';
-- 看某用户的权限
SHOW GRANTS FOR 'reader'@'%';
权限可以精确到库 → 表 → 列三级：GRANT SELECT (title, author) ON book_review.books TO ...——连「能看哪几列」都能管。
三、最小权限原则
| 角色 | 应给权限 | 绝不该给 |
|---|---|---|
| 前台展示网站 | SELECT | 一切写权限 |
| 书评写入接口 | INSERT + SELECT | DELETE、DROP |
| 运营修正数据 | UPDATE + SELECT | DROP、GRANT |
| DBA 本人 | 全部 | ——（连 DBA 也不该用 root 日常登录） |
逻辑链：权限越小 → 出事时的破坏半径越小。网页被注入攻击（SQL 注入）时，黑客拿到的正是网站账号的权限——网站只有 SELECT，他就只能偷看，删不了库。
四、动手 Demo：三账号分权（纸面 SQL，在线 MySQL 运行器可跑）
CREATE DATABASE book_review;
USE book_review;
CREATE TABLE books (id INT PRIMARY KEY, title VARCHAR(100));
-- 三个账号、三种命运
CREATE USER 'site' @'%' IDENTIFIED BY 'Site#2026'; -- 网站：只读
CREATE USER 'admin' @'%' IDENTIFIED BY 'Admin#2026'; -- 管理员：读写
GRANT SELECT ON book_review.* TO 'site'@'%';
GRANT SELECT, INSERT, UPDATE, DELETE ON book_review.* TO 'admin'@'%';
-- site 想删表 → 直接拒绝
-- GRANT 之外的操作对 site 全是 ERROR 1142
【准备块】在线 SQLite 运行器不支持用户系统，本 Demo 请用支持 MySQL 的在线运行器，或只读语法理解逻辑。
五、30 秒实验
打开手机「屏幕使用时间」或电脑的「来宾账户」：这就是操作系统版的最小权限——客人能上网，不能看你的文件。问：你公司的门禁卡能开几扇门？数据库账号同理。
六、常见误区
- 「一个 root 走天下最省事」：省的是配置的一时，出的是全库被拖的事故
- 「权限给了就完事」：人员离职、项目下线要及时 REVOKE——僵尸账号是经典后门
- 「只防外部黑客」：内部误操作（手滑
DELETE忘WHERE，3-12 的教训）同样要靠权限分级来限损
自测三问
1. GRANT 和 REVOKE 各干什么？（授予/收回权限） 2. 只读展示网站应给什么权限？（SELECT，精确到需要的表/列更好） 3. 为什么网站账号只给 SELECT 反而也是防注入手段？（注入攻击顶多借它的权限偷看，删不了库——最小化破坏半径）- ☐ 下一节（6-5 操作历史、日志、资源-监控数据库）
相关笔记
- 查询、限制、控制、访问权限、恢复-数据库的优势 —— 第一章点名的「控制、访问权限」，本节兑现成 SQL
- DELETE-删除记录 —— 忘 WHERE 全表遭殃：权限分级正是限损手段之一
- 操作历史、日志、资源-监控数据库 —— 下一节：权限管「准不准入」，日志管「干了什么」
- 🗄️ 数据库基础 · 索引 —— 全课路线图