摘要这篇笔记不聊虚的就用咱们手头的product表说话。很多初学者觉得select、where这些命令枯燥难记其实它们就是电商后台每天在用的最强“检索工具”。我会把这些语法揉进真实的商品管理场景里帮你摆脱死记硬背做到运营提需求你脑子里立刻能浮现出对应的 SQL。描述入职第一天运营的需求来了假设你刚接手一个电商后台负责商品模块。运营同事凑过来提了几个看似简单的要求“看看咱们都有啥分类”去重DISTINCT“找找 20005000 块的笔记本。”范围BETWEEN“搜下名字带‘霸’字的做个国潮专题。”模糊LIKE“导入的数据里有没有没分类的废品”空值NULL“衣服类目里哪个价位商品最多”分组GROUP BY“列表太长分个页一次 10 条。”分页LIMIT“按价格从高到低排下我看下贵的。”排序ORDER BY你看所有的需求本质都是在操作这张product表。接下来的内容我们就把这些需求一一落地。题解答案核心 SQL 汇总为了应对上述需求这几条 SQL 覆盖了后台 90% 的查询场景。-- 1. 商品列表后台首页基础版SELECTpid,pname,price,category_idFROMproduct;-- 2. 分类下拉框数据源去重SELECTDISTINCTcategory_idFROMproductWHEREcategory_idISNOTNULL;-- 3. 高价商品运营关注利润款SELECT*FROMproductWHEREpriceBETWEEN2000AND5000;-- 4. 指定分类查询如只关心电子和服装SELECT*FROMproductWHEREcategory_idIN(c001,c002);-- 5. 搜索框模糊查询SELECT*FROMproductWHEREpnameLIKE%霸%;-- 6. 数据清洗找异常数据SELECT*FROMproductWHEREcategory_idISNULL;-- 7. 分页查询每页10条取第1页SELECT*FROMproductLIMIT0,10;-- 8. 排序查询按价格降序SELECT*FROMproductORDERBYpriceDESC;-- 9. 聚合统计统计每个分类的商品数量SELECTcategory_id,COUNT(*)ASnumFROMproductGROUPBYcategory_id;题解代码深度分析这部分我们拆解每条 SQL 背后的业务含义和避坑指南。基础查询SELECT *是性能杀手-- 教学用不推荐生产环境SELECT*FROMproduct;-- 生产环境推荐写法SELECTpid,pname,price,category_idFROMproduct;为啥不用 *”性能*会读取所有字段万一以后表加了商品详情大文本查询速度会断崖式下跌。网络多查一个字段就多占一点带宽。高并发下省出来的带宽就是钱。健壮性表结构变了如字段改名*会直接报错而指定字段至少能提示缺字段方便排查。真实场景这叫 SQL 层面的 VOView Object前端需要啥你就查啥。DISTINCT不只是去重-- 场景获取所有分类ID用于前端筛选SELECTDISTINCTcategory_idFROMproduct;业务逻辑如果不去重1 万件商品就有 1 万个c001前端下拉框会直接崩掉。进阶SELECT DISTINCT price, category_id是“组合去重”。只有当“价格分类”都相同时才去重常用于排查同款商品。WHERE业务规则的翻译机范围查询 (BETWEEN)SELECT*FROMproductWHEREpriceBETWEEN2000AND5000;注意包左包右包含 2000 和 5000。如果要“大于 2000 且小于 5000”得用price 2000 AND price 5000。时间坑查某一天数据时BETWEEN 00:00:00 AND 23:59:59可能漏掉毫秒级数据建议用 第二天 00:00:00。IN的使用场景SELECT*FROMproductWHEREcategory_idIN(c001,c002);优于OR可读性强且在有索引时性能通常更好。前端多选框传来的数组直接拼成IN语句最顺手。NULL的判断大坑-- 错误写法永远查不到SELECT*FROMproductWHEREcategory_idNULL;-- 正确写法SELECT*FROMproductWHEREcategory_idISNULL;原理NULL代表“未知”不是空字符串。任何值与NULL运算结果都是假。数据导入后第一时间查NULL是数据清洗的必修课。模糊查询LIKE搜索的基石SELECT*FROMproductWHEREpnameLIKE%霸%;通配符%任意长度字符。_单个字符。性能红线LIKE 霸%前缀匹配能走索引。LIKE %霸%全模糊全表扫描千万级数据直接卡死。解决方案Elasticsearch 或限制只能前缀搜索。排序 (ORDER BY) 与 分页 (LIMIT)-- 按价格降序取前10SELECT*FROMproductORDERBYpriceDESCLIMIT10;-- 分页第2页每页5条SELECT*FROMproductLIMIT5,5;深度分页问题LIMIT 100000, 10意味着数据库要先扫 10 万条数据再取 10 条越往后翻越慢。执行顺序先WHERE过滤再ORDER BY排序最后LIMIT截取。聚合与分组 (GROUP BY)-- 统计各类商品数量SELECTcategory_id,COUNT(*)ASproduct_countFROMproductGROUPBYcategory_id;逻辑先按category_id分堆再数每堆的数量。HAVING过滤WHERE过滤行HAVING过滤分组后的结果。例如HAVING COUNT(*) 3只显示商品数大于 3 的分类。别名 (AS)说“人话”SELECTpidAS商品编号,price*0.9AS折后价FROMproduct;必要性导出 Excel 给运营或财务price不如“售价”直观计算字段必须有别名否则列名就是乱码。更多实战场景与 SQL 示例为了让你更通透补充 20 个高频业务场景场景一价格调整算术运算需求双十一打 9 折。SELECTpname,priceAS原价,price*0.9AS双十一价FROMproduct;场景二排除特定分类需求不看服装类。SELECT*FROMproductWHEREcategory_id!c002;场景三多条件联合精准需求服装类且价格大于 500。SELECT*FROMproductWHEREcategory_idc002ANDprice500;场景四多条件任选需求电子产品或百元以下商品。SELECT*FROMproductWHEREcategory_idc001ORprice100;场景五复杂逻辑组合需求服装且贵或化妆品。SELECT*FROMproductWHERE(category_idc002ANDprice500)ORcategory_idc003;场景六区间之外需求排除 100-500 元区间。SELECT*FROMproductWHEREpriceNOTBETWEEN100AND500;场景七指定品牌需求只看“联想、海尔、雷神”。SELECT*FROMproductWHEREpnameIN(联想,海尔,雷神);场景八二字商品名需求找“劲霸”、“面霸”。SELECT*FROMproductWHEREpnameLIKE__;场景九多字段排序需求先按分类再按价格降序。SELECT*FROMproductORDERBYcategory_idASC,priceDESC;场景十总商品数需求SKU 总量。SELECTCOUNT(*)AStotal_countFROMproduct;场景十一有效商品数需求排除脏数据。SELECTCOUNT(*)FROMproductWHEREcategory_idISNOTNULL;场景十二分类均价需求评估品类档次。SELECTcategory_id,AVG(price)ASavg_priceFROMproductGROUPBYcategory_id;场景十三最贵商品需求镇店之宝。SELECT*FROMproductORDERBYpriceDESCLIMIT1;场景十四最便宜商品需求引流款。SELECT*FROMproductORDERBYpriceASCLIMIT1;场景十五排除特定前缀需求不看“香”字开头商品。SELECT*FROMproductWHEREpnameNOTLIKE香%;场景十六空字符串判断需求区分NULL和空字符串。SELECT*FROMproductWHEREcategory_id;场景十七排除无效分类需求既不是NULL也不是空。SELECT*FROMproductWHEREcategory_idISNOTNULLANDcategory_id!;场景十八标准分页写法需求MySQL 8.0 推荐。SELECT*FROMproductLIMIT10OFFSET0;场景十九查看表结构需求新人接手代码。DESCproduct;SHOWCREATETABLEproduct;场景二十空结果测试需求测试接口健壮性。SELECT*FROMproductWHEREpname根本不存在的商品名;示例测试及结果分析测试一分类统计SELECTcategory_id,COUNT(*)ASnumFROMproductGROUPBYcategory_id;结果c002(服装) 有 5 个NULL有 1 个苹果18PM。解读运营一眼看出服装品类最丰富且存在一条待处理脏数据。测试二模糊查询排序SELECTpname,priceFROMproductWHEREpnameLIKE%霸%ORDERBYpriceDESC;结果劲霸(2000) - 面霸(10)。解读验证了 SQL 执行顺序——先WHERE过滤出两条再ORDER BY排序。时间复杂度与性能分析全表扫描 (O(n))SELECT *、LIKE %x%。数据翻倍时间翻倍。索引查找 (O(log n))WHERE category_id c002有索引时。数据翻 10 倍耗时微增。排序 (Filesort)ORDER BY无索引时需在内存/磁盘排序极慢。分组 (Temporary Table)GROUP BY类似排序耗内存。结论小数据量随便写大数据量下SELECT *和%xxx%是性能杀手。空间复杂度临时表DISTINCT、GROUP BY会产生临时表大数据集会撑爆内存。网络缓冲SELECT *占用大量网络带宽。排序缓冲ORDER BY依赖排序缓冲区过小则写磁盘速度骤降。总结这一整套 SQL就是电商后台的“商品查询引擎”。查什么SELECT拒绝*。怎么筛WHERE业务逻辑的核心。怎么搜LIKE警惕%开头。怎么排ORDER BY列表页的灵魂。怎么统GROUP BY运营报表的基础。怎么清NULL数据质量的底线。当你能把运营的一句“帮我找下…”瞬间翻译成高效的 SQL你就不再是语法搬运工而是真正的后端开发。写 SQL 就像说话想清楚再说数据库自然听话。