第2章 处方规范：SQL语言基础

第 2 章 · 处方规范：SQL 语言基础

本章要回答的三个问题：一张表该怎么建才不给未来埋雷？日常增删改查有哪些写法会直接引发性能事故？权限和事务语句在处方里扮演什么角色？

为什么会有这一章

SQL 是诊断室里的处方笺。处方写错，轻则药效不足（查询慢），重则医疗事故（误删数据）。很多性能病例的根因不在数据库配置，而在建表时选错了类型、查询时写出了让优化器无法下咽的语句。这一章把 DDL、DML、DQL、DCL、事务语句按"处方规范"的口径过一遍，为第 4 章的手术做准备。

读完能解决什么

• 会设计类型合适的表结构，明白 VARCHAR 长度、NULL 的代价
• 掌握增删改查的安全写法与危险写法
• 理解 GRANT/REVOKE 的最小权限思路与事务控制语句

各节怎么分工

先决条件

第 1 章搭好的诊断环境，能用 trainee 账号连接。

往下走到哪

处方会写了，第 3 章解剖这台"机器"——SQL 交上去之后，MySQL 内部到底发生了什么。

处方笺上的红线

这一章贯穿一条隐线：写 SQL 的自由度很大，但自由度越大越需要自律。2.1 节的红线是类型与 NULL——金额用了浮点、时间存成字符串，这类错误在表建好那天就埋下，改动成本随数据量指数上升。2.2 节的红线是无 WHERE 的更新和深翻页的 OFFSET，前者是事故，后者是慢性病。2.3 节的红线是万能权限账号和塞满慢操作的长事务，它们分别在第 7 章和第 5 章会回来收账。

读的时候可以给自己出题：每学一条规范，先想"违反它会出什么事、什么时候出"。能答出事故形态的规范才是真正内化的规范，否则只是抄在墙上的标语。练习环境里故意违反一次、亲眼看一次翻车现场，印象远比背诵深刻。

本章的示例表会在第四第五两章反复出场，建表语句值得亲手敲一遍而不是复制粘贴——手指的记忆在排错时也会帮忙。

一张自检清单

离开本章前拿这张清单过一遍自己的建表与查询习惯：金额列是不是 DECIMAL；时间列是不是原生类型；每列是不是都考虑过 NOT NULL；UPDATE 与 DELETE 是不是都先 SELECT 过范围；大变更是不是都分批带 LIMIT；深分页接口是不是游标化；应用账号是不是只有 DML；事务里是不是只有 DML 且足够短。八条全绿，第 4 章的手术台就干净了一半——索引能救的是写得对的 SQL，救不了写错的数据模型。

清单里任何一条变红都别急着改表，先估数据量与影响面：百万行以下的表多数问题可以在线改完，千万行以上的表改模型要走第 2.1 节的大表流程或第 8 章的在线工具。处方开多猛，取决于病人的体重。
再给一个练习题收束本章：给自己负责的一张核心表写三样东西——一份建表 DDL（类型逐列有理由）、一条最常执行的查询（检查它有没有守本章的规矩）、一份该表的权限现状（谁能写它、该不该）。三样写完互相印证，本章的知识点就落到了你自己的病人身上。处方规范从来不是背诵题，是每张表都要交的作业。
本章还埋了一条通往第 7 章的线：DCL 小节的权限模板到了防疫科会扩成三角色体系，事务小节的短事务纪律到了第 5 章会长成完整的锁管理。SQL 语言层的规范看似琐碎，它约束的却是数据库世界里成本最高的两类事故——数据错误与并发失控，两者的种子都在一句句看似平常的语句里。把处方笺写规范，后面两间科室的工作量会少一半。