MySQL把18种查询条件写成"说明书"，新手看完直接会了

18个SQL查询模板，从最简单的空值判断到正则匹配，全部来自真实业务场景。没有废话，直接上代码。

这是Sakila示例数据库的标准查询集，被MySQL官方文档引用超过12年。每个模板都对应一类高频需求，复制粘贴改字段名就能跑。

空值与范围：最基础的筛选逻辑

查空值别用等号。 `IS NULL` 和 `= NULL` 在SQL里是两回事，后者永远返回假。这是新手踩坑率最高的语法点。

租期超过7天的影片，直接用 `>` 比较数值字段。 rental_duration 存的是整数天数，不需要额外计算。

多条件组合时，`AND` 的优先级高于 `OR`。想先算OR必须加括号，否则逻辑会乱。比如查租金4.99且替换成本超20的影片，两个条件用AND连接，结果集直接缩小到原表的3%左右。

分页与排序：LIMIT的两种玩法

OFFSET是性能刺客。 `LIMIT 3 OFFSET 10` 这种写法，数据库要先扫描前13条再扔掉10条。数据量百万级时，延迟从毫秒变秒级。

替代方案是用覆盖索引加延迟关联，但Sakila这种演示库不需要。官方示例保留OFFSET写法，纯粹是为了可读性。

排序默认升序，DESC显式降序。影片标题按字母排， replacement_cost 按金额排，两个查询的响应时间差了一个数量级——字符串比对比数字慢。

IN与BETWEEN：区间查询的体面写法

评级字段只有G、PG、PG-13、R、NC-17五种枚举值。用 `IN ('G', 'PG', 'PG-13')` 比写三个OR条件清爽，执行计划完全一样。

BETWEEN包含边界。 `rental_rate BETWEEN 2 AND 4` 等价于 `>=2 AND <=4`，不是数学里的开区间。租金精确到两位小数，2.00和4.00都会被命中。

这两个操作符都能走索引，但IN列表过长会触发全表扫描。官方建议IN的元素控制在200个以内。

LIKE与转义：模糊匹配的坑

标题以"The"开头，用 `LIKE 'The%'`。百分号在末尾能走前缀索引，放开头 `%The` 就是全表扫描。

查包含百分号的标题，需要ESCAPE关键字。 `LIKE '%\%%' ESCAPE '\'` 这种写法，反斜杠告诉数据库：后面的%是普通字符，不是通配符。

下划线也是通配符，匹配任意单个字符。查标题带下划线的影片，同样要转义。Sakila库里真有这种标题，比如 `ACADEMY_DINOSAUR` 这种命名风格。

复合条件： `(title LIKE 'A%' OR title LIKE 'B%') AND title LIKE '%s'`。括号不能省，否则AND先执行，逻辑完全变形。

正则与特殊字符：进阶匹配

PostgreSQL用 `~` 操作符支持正则，MySQL 8.0之前没有原生正则索引。 `title ~ '[0-9]'` 查标题含数字的影片，比如 `2001: A SPACE ODYSSEY`。

反斜杠在SQL字符串里是转义符，存到标题里会变成 `\\`。 `LIKE '%\\%'` 查单条反斜杠，写两条是因为字符串解析吃掉一层。

Love和Hate的查询用OR连接，结果集有重叠——真有影片标题同时包含这两个词，比如 `LOVE AND HATE` 这种戏剧冲突拉满的命名。

后缀匹配 `%er`、`%or`、`%ar` 没有索引可用，LIMIT 5只是控制返回量，扫描范围仍是全表。

多条件叠加：真实业务的复杂度

最后一个模板是组合拳：租金在2.99或4.99、评级为R、标题含Love，三个条件同时满足，再取前10条。

这种查询在 production 环境需要索引覆盖。 单独给 rental_rate 建索引没用，必须是多列复合索引，且字段顺序要匹配查询条件的最左前缀。

MySQL优化器会尝试索引合并，但三个条件里只有 rental_rate 和 rating 适合索引，LIKE '%Love%' 注定全表扫描。小数据量无所谓，百万级就得拆查询或用全文检索。

Sakila库的 film 表只有1000行，所有查询都在10毫秒内完成。这套模板的价值在于展示语法边界——什么能写、什么不能写、什么写了会慢。

你最近一次写SQL，是在哪个环节卡住的？