![]()
一个电影租赁数据库,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查询,通配符位置决定了能不能用上索引,也决定了查询性能的天壤之别。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.