SQL查询把电影库翻了个底朝天：15个实战技巧让检索效率飙3倍

一个电影租赁数据库，1000行数据，15种查询场景。这不是面试题，是某个开发者在练习SQL时的真实记录。从基础筛选到复杂模式匹配，每个查询都对应着业务里的真实痛点。

很多人写SQL有个毛病：能跑通就行。但数据量上来后，同样的需求，写法不同性能差出十倍。下面这15个查询，从简单到复杂，藏着不少值得细品的细节。

基础筛选：AND和OR的陷阱

最基础的查询，租金大于3美元的电影。写法简单粗暴，但已经暴露问题：SELECT * 在大表上是性能杀手。

第二个查询加了AND条件，租金大于3美元且替换成本低于20美元。这里有个细节：AND的优先级天然高于OR，所以这种写法不需要括号。但一旦混用OR，括号就是救命符。

第三个查询是PG分级或者租金0.99美元。这种"或"条件在业务里常见——给用户多一个选择入口。但索引设计时得小心，OR条件经常让索引失效。

这三个查询的租金阈值分别是3美元、20美元、0.99美元，全是业务里的关键定价节点。

排序与分页：LIMIT不是免费的

第四个查询要租金最高的10部电影。DESC降序排，LIMIT截断。看起来没问题，但如果rental_rate没有索引，数据库得全表排序。

第五个查询玩了个花样：跳过前5条，取接下来的3条。OFFSET 5 LIMIT 3，典型的分页写法。但OFFSET有个坑：数值越大越慢，因为数据库还是得从头数过来。

第六个按片名排序取前5个，第七个按替换成本降序跳过前10个取3个。这两个查询在测试分页逻辑时常用，但生产环境深度分页建议用游标或者覆盖索引。

第八个查询有点意思：替换成本最高的5部，但要跳过最贵的那部。OFFSET 1 LIMIT 5，这种"第二名到第六名"的需求在排行榜场景很常见。

分页查询的OFFSET值从5到10不等，但性能瓶颈往往不在LIMIT而在OFFSET。

范围查询：BETWEEN的边界

第九个查询用BETWEEN找租赁时长3到7天的电影。BETWEEN在SQL里是闭区间，包含两端。很多新手以为是左闭右开，结果把边界数据漏了或者多算了。

第十个查询是日期范围，2005年5月1日到6月1日的租赁记录。日期格式用字符串，依赖数据库隐式转换。这种写法能跑，但严格来说该用DATE或者TIMESTAMP类型，避免时区和格式陷阱。

两个BETWEEN查询，一个整数范围一个日期范围，边界处理是同样的逻辑。

模式匹配：LIKE的15种打开方式

第十一个查询：片名以A开头、e结尾。LIKE 'A%e'，百分号通配中间任意字符。这种"首尾锚定"的查询，如果字段有索引，数据库可能用不上——因为通配符在前面。

第十二个更复杂：A开头或B开头，都得s结尾。括号把两个OR条件包起来，避免优先级混乱。没有括号的话，逻辑可能变成"A开头，或者（B开头且s结尾）"，结果全变。

第十三个查询找含Man、Men、Woman的片名。三个OR条件，每个都用前后百分号。这种查询在全文检索场景性能极差，数据量大了得换Elasticsearch或者数据库全文索引。

第十四个简单：The开头的片名。'The%'，通配符只在末尾，这种写法数据库可以用上索引。如果字段建了B-Tree索引，查询能走范围扫描。

第十五个查询含Love或Hate的片名。情感关键词搜索，前后通配的老问题。但业务上这种需求躲不掉，用户就是想要搜"爱情片"或者"复仇片"。

五个LIKE查询，通配符位置决定了能不能用上索引，也决定了查询性能的天壤之别。