本章要回答的三个问题:转账扣款成功、入账还没执行就断电,数据库怎么保证两步要么都成、要么都不算?为什么实习生不该有 DROP 权限,GRANT 与 REVOKE 怎么按角色精确放权?什么样的逻辑值得从应用层搬进数据库,存储过程、触发器、动态 SQL 各自的适用与滥用边界在哪里?查询之外,这是 SQL 工程能力的另一半。
前八章都在"把数据取对",本章解决"把数据守对"。第 2 章末尾用过一次事务后悔药,但那只是感性认识:为什么 BEGIN 之后改动可以整批撤销?并发之下两个事务同时改一行会怎样?ACID 四个字母各自对应什么机制?这些答案决定你敢不敢在生产环境写 UPDATE。
权限与可编程对象则是工程团队的日常:新人入职要开只读账号、报表服务要开指定库的查询权、误授权的事故复盘里 REVOKE 是止损动作;而"库存扣减不能为负"这类规则写在应用层就存在被绕过的可能,搬进数据库(约束、触发器、存储过程)才是最后防线——但搬进去的代价是逻辑分散、调试困难,边界的拿捏正是本节的分量所在。
| 节 | 回答哪个问题 | 关键产出 |
|---|---|---|
| 9.1 事务与 ACID | 怎么同生共死 | 四特性拆解、保存点、隔离级别速览 |
| 9.2 权限管理 | 谁能动什么 | GRANT/REVOKE 全流程、最小权限实践 |
| 9.3 存储过程、触发器与动态 SQL | 规则搬进数据库吗 | 可编程对象选型、动态 SQL 风险 |
查询能力决定你能做什么,守护能力决定你敢做什么。生产环境的分界线就在这一章。
数据守住了,最后一章回答"怎么跑得快":索引怎么把全表扫描变成定点查找,EXPLAIN 的每一行在说什么,以及登上台阶顶端之后的进阶路线图。带着本章的守护能力向上爬,速度才有意义——没有安全感的快,只是加速靠近事故。