电影、演员、票房这三块数据凑在一起是练 SELECT 最合适的素材——它有维度、有事实、有一对多关系还有一层电影属于谁、谁演了哪部、演了什么角色、拿了多少票房的天然层级。最近带一组同学做这套查询练习发现卡点几乎不在语法上而是卡在我到底该先想表关系还是先想字段这一步。有人把 FROM 后面一股脑塞进四张表跑出来几百行笛卡尔积还在纳闷数据怎么变多了有人 GROUP BY 写完发现 SELECT 里带了个没聚合的列报错信息翻来覆去看不懂还有人条件里写了year NULL结果一行都没查出来回头把 NULL 改成NULL字符串反倒有结果了。这些都不是知识没学会是没人把为什么这样写不报错、那样写报错讲透。这里想做的很具体拿一套电影、演员、票房的小型数据集把 SELECT 从建表、筛选、分组、连接到子查询这条线完整走一遍每一步都说清楚为什么这么写和写错了会怎样。不管你是刚接触 SQL 的在校学生还是工作里要临时出几条统计报表的后端只要手上有 MySQL 环境照着敲一遍就能上手遇到同类业务也能直接套。1. 这套数据集为什么必须是四张表而不是一张1.1 从业务关系倒推表结构如果只做查电影名这种题一张表就够了。但只要题目里出现演员和票房一张宽表就会立刻露馅。原因很简单一部电影可能有七八个演员如果全塞在一行里actor_name就得写成演员甲,演员乙,演员丙这种字符串后面想统计每个演员参演了几部片就只能对字符串做拆分匹配查询复杂度和出错概率都成倍上升。这是典型的多对多关系必须用一张中间表拆开。更关键的是票房和电影是一对一、演员和电影是多对多、演员本身是独立实体。数据建模的基本判断标准是一个实体有自己稳定的属性且会被多处引用就该单独成表。演员的出生年份、性别、国籍不属于某一部电影它属于演员本人如果挂在电影表上同一个演员演了十部片他的出生年份就要重复存十次改一次要改十处。这就是冗余的代价。具体到这套数据集四张表的分工是这样的表名角色关键字段关系类型movies事实主体movie_id、title、release_year、genre主表actors独立维度actor_id、actor_name、country被引用方movie_actor桥接表movie_id、actor_id、role_name、is_lead多对多桥梁box_office扩展事实movie_id、total_wan、ticket_count、market与 movies 一对一这里有个容易被忽略的判断box_office 为什么不直接合并进 movies。技术上合并完全可行但业务上票房数据往往来自另一个系统字段更新节奏不同有些片子还没上映、票房为空有些是分批汇总的。拆表之后没票房记录这件事可以用关联不上来表达就不用往 movies 里塞一堆 NULL。这个习惯在真实项目里特别值钱做数仓的人管这叫事实与维度分离。1.2 建表语句与一小份能手算得出来的样本练查询最忌讳一上手就是几十万条数据。正确做法是先造五六条、能自己心算出答案的数据写完查询对着心算结果核这样出错能立刻定位是逻辑问题还是数据问题。CREATE TABLE movies ( movie_id INT PRIMARY KEY, title VARCHAR(100) NOT NULL, release_year SMALLINT, genre VARCHAR(30), duration_min SMALLINT, director VARCHAR(50), country VARCHAR(30), budget_wan DECIMAL(10,2) ); CREATE TABLE actors ( actor_id INT PRIMARY KEY, actor_name VARCHAR(50) NOT NULL, gender CHAR(1), birth_year SMALLINT, country VARCHAR(30) ); CREATE TABLE movie_actor ( movie_id INT, actor_id INT, role_name VARCHAR(50), is_lead TINYINT, PRIMARY KEY (movie_id, actor_id) ); CREATE TABLE box_office ( movie_id INT PRIMARY KEY, opening_wan DECIMAL(10,2), total_wan DECIMAL(10,2), ticket_count INT, market VARCHAR(20) );灌数据的时候我习惯按这个顺序写先 movies再 actors然后 movie_actor最后 box_office。原因不是习惯问题而是外键依赖顺序——桥接表引用了前两张表的主键先插父表再插子表否则一旦开了外键约束就会直接报错。这份样本里我会故意留三种特殊情况一部电影没有任何演员记录、一位演员没有参演任何电影、一部电影票房表里没有对应行。这三种缺口是后面练 LEFT JOIN 和 NULL 判断的靶子不加进去练题的时候永远想不到。提示样本数据宁可少而有坑不要多而平滑。五条数据里藏三个缺口比五百条干净数据的学习价值高得多。1.3 字段类型的三个隐性陷阱第一个是年份。很多人顺手把release_year定义成DATE或者VARCHAR。用DATE的话插入时被迫补一个01-01后面按年份筛选就得写YEAR(release_year) 2019函数一包索引就废了用VARCHAR更糟字符串排序下1000 2019没问题但一旦出现99这种短年份就会乱序。年份本质是个整数用SMALLINT最省事筛选直接release_year BETWEEN 2015 AND 2020干净利落。第二个是金额。票房用DECIMAL(10,2)还是INT存万元如果业务只关心到万元整数INT够用且快但只要有小数就必须DECIMAL绝不能用FLOAT。浮点数做求和会出现1234.5600000000001这种尾巴SUM之后拿去和另一个数比相等永远比不中。财务类字段用浮点是行业公认的自找麻烦。第三个是空值的含义漂移。NULL在这套数据里至少有两种语义一种是未知比如某部老片子的预算查不到了另一种是不适用比如还没上映的电影票房记录不存在。这两种在业务解释上完全不同但存进去都是NULL。我的建议是能不存也别存用关联不上来表达没有真需要存的时候在字段注释里写清楚到底是哪种语义不然三个月后自己都分不清。2. 书写顺序和执行顺序压根不是一回事2.1 你写的顺序数据库不照着跑这是 SELECT 最核心的一个认知差。人写 SQL 的顺序是SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT因为这样读起来顺。但数据库引擎的执行顺序完全是另一套FROM → ON → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT这个顺序不是学术摆设它直接决定了很多写法为什么会报错。举一个最常见的例子WHERE在SELECT之前执行也就是说WHERE执行的时候SELECT里起的别名还不存在。所以下面这句必然报错-- 错误示范 SELECT total_wan / 10000 AS total_yi FROM box_office WHERE total_yi 5;而ORDER BY在SELECT之后执行别名已经算出来了所以同样用别名放ORDER BY里就合法-- 正确写法 SELECT total_wan / 10000 AS total_yi FROM box_office ORDER BY total_yi DESC;理解这个顺序之后很多莫名其妙的报错会瞬间变得可解释。比如HAVING在GROUP BY之后、SELECT之前所以HAVING里可以用聚合函数WHERE里不行——因为WHERE干活的时候分组还没发生哪来的聚合结果。这不是规定是时序决定的。2.2 一条最小骨架的固定套路我要求自己带的人写每一条查询都先落这个骨架再往里填肉SELECT [要什么列 / 聚合] FROM [主表] JOIN [关联表] ON [关联条件] WHERE [行级过滤] GROUP BY [分组维度] HAVING [组级过滤] ORDER BY [排序规则] LIMIT [条数];骨架的价值在于它逼你先回答结果一行代表什么。这个问题的答案决定了有没有GROUP BY一行代表一部电影那就不分组一行代表一个演员的汇总那就按演员分组。我见过太多人上来就写GROUP BY写完发现维度选错了整条重写。先想清楚粒度再想列最后想过滤这个顺序比反过来效率高一大截。另外提醒一个细节ORDER BY后面没写方向默认是ASC但排序规则里如果有NULLMySQL 把NULL排在最小ASC时它们会跑到最前面。统计票房排行榜的时候票房为空的片子占据榜首就是踩了这个坑。要处理得写ORDER BY total_wan DESC配合WHERE total_wan IS NOT NULL或者用ORDER BY total_wan IS NULL, total_wan DESC把空值压到最后。3. WHERE 里那几个最容易翻车的点3.1 AND 和 OR 的优先级会悄悄改写你的条件AND的优先级高于OR这是硬规则。所以下面这句SELECT title, genre, release_year FROM movies WHERE genre 科幻 OR genre 悬疑 AND release_year 2018;它并不是科幻或悬疑且 2018 年后而是科幻或者悬疑且 2018 年后。2019 年的科幻片会进结果2015 年的科幻片也会进这显然不是本意。正确写法必须加括号WHERE (genre 科幻 OR genre 悬疑) AND release_year 2018;提示只要WHERE里同时出现AND和OR无条件加括号。这条规则没有例外加了永远不会错不加迟早会错。3.2 NULL 参与的比较既不是真也不是假SQL 用的是三值逻辑真、假、未知。NULL参与任何比较运算结果都是未知而WHERE只放行真。所以total_wan NULL、total_wan NULL、total_wan NULL全是未知一行都查不出来。判断空值只能用IS NULL和IS NOT NULL。更隐蔽的是NOT IN遇到NULL。假设你要查没有参演任何电影的演员写成-- 危险写法 SELECT actor_id, actor_name FROM actors WHERE actor_id NOT IN (SELECT actor_id FROM movie_actor);只要子查询结果里出现一个NULL整个NOT IN就永远返回空集。原因是x NOT IN (1, 2, NULL)等价于x 1 AND x 2 AND x NULL最后一项是未知整体就塌了。这个问题在真实项目里坑过无数人因为生产数据的关联字段经常有空值。稳妥写法是排除空值或者改用NOT EXISTSSELECT a.actor_id, a.actor_name FROM actors a WHERE NOT EXISTS ( SELECT 1 FROM movie_actor m WHERE m.actor_id a.actor_id );3.3 LIKE 的匹配范围藏在通配符的位置LIKE %科幻%、LIKE 科幻%、LIKE %科幻这三者结果完全不同通配符位置决定匹配范围。前两个好理解第三个容易误判成以科幻结尾其实它就是以科幻结尾只是很多人写%的时候不过脑子。真正的坑是转义。电影名里带下划线_的LIKE 星_渡口里的_会被当作任意单字符通配符能匹配到星河渡口也能匹配到星汉渡口。要精确匹配下划线必须转义SELECT title FROM movies WHERE title LIKE 星\_渡口;另一个隐形问题是LIKE %关键字%这种前后都带通配符的写法会走全表扫描索引完全用不上。数据量小的时候没感觉几百万行的时候能慢到你以为数据库挂了。如果业务上真要做关键词搜索就别指望普通索引老老实实上全文索引或者交给专门的检索组件别硬扛。3.4 IN 和 BETWEEN 的边界语义要记牢BETWEEN a AND b是闭区间两端都包含。这一点写区间统计的人必须刻在脑子里否则算年度票房的时候会把上一年的最后一天重复算进来。IN的列表是精确匹配IN (2018, 2019, 2020)等价于三个OR但可读性和执行计划都更好。需要注意IN列表太长几千个值的时候解析开销会明显上升这时候改成临时表关联更合适。还有一点IN里混合类型会触发隐式转换比如movie_id IN (1, 2)传的是字符串MySQL 会把列转成字符串来比索引失效。这个坑在程序里拼 SQL 时特别常见因为参数从接口传进来往往都是字符串。4. 分组聚合才是票房统计的主战场4.1 GROUP BY 的本质是先切块再算数很多人把GROUP BY理解成合并行其实更贴切的比喻是先按维度把数据切成若干堆每堆压成一行。切块的依据是GROUP BY后列的取值组合堆内做聚合运算最后每堆输出一行。理解这个切块模型GROUP BY genre, release_year就好懂了它切出来的是科幻-2018科幻-2019悬疑-2018这样的组合块不是先按类型再按年份的两级分组。统计每个类型电影的票房总和与平均票房标准写法是SELECT m.genre, COUNT(*) AS movie_cnt, SUM(b.total_wan) AS total_wan, ROUND(AVG(b.total_wan), 2) AS avg_wan FROM movies m JOIN box_office b ON b.movie_id m.movie_id GROUP BY m.genre ORDER BY total_wan DESC;这里有个业务判断必须提前想清楚统计每类型总票房时那些没有票房记录的电影参不参与。用JOIN会把它们直接丢掉用LEFT JOIN会保留但算出来是NULL而AVG计算时会自动忽略NULL导致分子分母的口径不一致。我的做法是显式说明要么在WHERE里限定b.total_wan IS NOT NULL明确只统计有数据的要么在AVG外面包COALESCE补零。含糊不清的统计口径比算错还麻烦。4.2 WHERE 和 HAVING 的分界线只有一条一句话记WHERE 过滤行HAVING 过滤组。凡是要用聚合结果做条件的必须放HAVING凡是能用原始列判断的一律放WHERE。-- 找出参演演员数不少于 2 人、且平均票房超过 8000 万的类型 SELECT m.genre, COUNT(DISTINCT ma.actor_id) AS actor_cnt, ROUND(AVG(b.total_wan), 2) AS avg_wan FROM movies m JOIN movie_actor ma ON ma.movie_id m.movie_id JOIN box_office b ON b.movie_id m.movie_id WHERE m.release_year 2015 GROUP BY m.genre HAVING actor_cnt 2 AND avg_wan 8000;为什么release_year 2015放WHERE不吝HAVING因为它是行级条件早点过滤掉能减少参与分组的数据量性能更好。反过来actor_cnt 2依赖聚合结果只能放HAVING放到WHERE会直接报未知列。这个分工不是风格问题是执行顺序决定的硬约束。4.3 COUNT 的三种写法差异很大COUNT(*)、COUNT(col)、COUNT(DISTINCT col)结果经常不一样选错就是统计错误写法行为典型用途COUNT(*)统计行数不关心内容含全 NULL 行总记录数、订单量COUNT(col)只统计该列非 NULL 的行有效数据量、非空填报率COUNT(DISTINCT col)去重后统计参演演员数、独立用户数统计每部电影的参演人数如果actor_id不可能为空COUNT(*)和COUNT(actor_id)结果一样但一旦桥接表里存在占位行比如某些导入数据用空演员占位COUNT(*)就会多算。而参演演员数这个指标本质要的是去重人数同一演员在同一部片里理论上不该出现两次但数据脏的时候真会出现所以我习惯写COUNT(DISTINCT actor_id)兜底。4.4 ONLY_FULL_GROUP_BY 报错该怎么读MySQL 5.7 之后默认开启ONLY_FULL_GROUP_BY很多人写下面这句就报错-- 报错Expression #2 of SELECT list is not in GROUP BY clause SELECT genre, title, SUM(total_wan) FROM movies m JOIN box_office b ON b.movie_id m.movie_id GROUP BY genre;报错信息看着吓人其实说的是你按类型分组了每个类型可能对应多部电影那title到底该输出哪一部数据库不知道所以拒绝执行。这个报错是好事它拦住了你输出一个随机的值。解决办法有三条路选哪条取决于业务语义一是把title也从SELECT里删掉多数情况这才是正解二是把title加进GROUP BY等于改变分组粒度要确认这是你要的三是用MAX(title)、GROUP_CONCAT(title)这类聚合函数明确表态我要的是一个代表值。我最推荐第一条因为绝大多数这类报错本质是把明细和汇总混在了一条查询里。5. 多表连接演员和电影到底怎么接5.1 笛卡尔积是怎么莫名其妙冒出来的FROM movies, movie_actor这种逗号写法如果不加WHERE关联条件结果行数是两张表行数的乘积。5 部电影 × 12 条演员关联 60 行看着不多一旦换成几千乘几万就是上亿行查询直接卡死。笛卡尔积出现的典型场景有三个忘了写关联条件、关联条件写在WHERE里但用了OR把条件短路了、JOIN写成了CROSS JOIN。排查方法很直接把SELECT *改成SELECT COUNT(*)跑一下行数明显大于主表行数基本就是哪里漏了约束。还有一个更隐蔽的情况关联字段类型不一致。movies.movie_id是INT而某张导入表里的movie_id是VARCHAR关联时会发生隐式转换某些值比如001和1转出来匹配不上看着不报错实际少了一批数据。这种情况最难查因为查询本身语法完全合法。我的习惯是建表时就把关联字段类型对齐宁可多花五分钟也别在结果对不上的时候花五小时。5.2 INNER JOIN 和 LEFT JOIN 决定的是谁必须存在这是连接查询里最需要先想明白的一件事。INNER JOIN只保留两边都能对上的行LEFT JOIN保留左表全部行右表对不上就补NULL。回到这套数据要查所有演员及其参演电影数包括那些一部戏都没接的演员必须用LEFT JOINSELECT a.actor_id, a.actor_name, COUNT(ma.movie_id) AS movie_cnt FROM actors a LEFT JOIN movie_actor ma ON ma.actor_id a.actor_id GROUP BY a.actor_id, a.actor_name ORDER BY movie_cnt DESC;注意这里写的是COUNT(ma.movie_id)而不是COUNT(*)。如果写COUNT(*)没接戏的演员也会被算成 1因为LEFT JOIN会给他补一行全NULL的记录而COUNT(*)数的是行数。这是LEFT JOIN做统计时最高频的错误几乎每次带人练都会撞上。ON和WHERE在LEFT JOIN里的区别也要说清楚。下面两种写法结果完全不同-- 写法一先连接再过滤票房为空的电影会被过滤掉退化成 INNER JOIN SELECT m.title, b.total_wan FROM movies m LEFT JOIN box_office b ON b.movie_id m.movie_id WHERE b.total_wan 10000; -- 写法二连接时就带上条件没票房的电影仍会保留只是票房列全为 NULL SELECT m.title, b.total_wan FROM movies m LEFT JOIN box_office b ON b.movie_id m.movie_id AND b.total_wan 10000;区别的根源还是执行顺序ON在连接阶段生效WHERE在连接完成之后生效。WHERE里对右表列做非空判断等于把补出来的NULL行又删掉了LEFT JOIN白写。这个点我在实际写报表时特别小心因为它不报错、只是结果悄悄少了行最难被发现。5.3 表别名不只是省字它是防歧义的基础设施四张表里movie_id出现了三次country出现了两次。不写别名直接SELECT movie_idMySQL 会报Column movie_id in field list is ambiguous。即使不报错读代码的人也没法一眼看出这个字段来自哪张表。我的习惯是每个表都给短的、有意义的别名movies m、actors a、movie_actor ma、box_office b。所有列统一加前缀一个都不例外。这条规矩看着死板但在多表连接里能省掉大量排查时间——ORDER BY里少加前缀导致排序结果诡异、SELECT里引用了错误的同名列这类问题在有前缀的情况下根本不会发生。6. 子查询与排名、占比、对比这类绕不开的问题6.1 标量子查询把一条查询的结果当成一个值找出票房高于全片平均票房的电影这句话天然翻译成两层先算全片平均再拿每部片子去比。SELECT m.title, b.total_wan FROM movies m JOIN box_office b ON b.movie_id m.movie_id WHERE b.total_wan (SELECT AVG(total_wan) FROM box_office) ORDER BY b.total_wan DESC;括号里那条子查询只返回一个值所以可以直接用比较这叫标量子查询。它有个硬约束必须只返回一行一列多一行就报Subquery returns more than 1 row。所以用的时候要么确定结果唯一要么在子查询里加LIMIT 1兜底。有个细节值得说AVG计算时会忽略NULL所以这个平均票房是有票房记录的电影的平均值不含那些没有数据的片子。这和业务上理解的全片平均可能有偏差。我一般会在这类查询旁边加一行注释说明口径因为报表被人追问为什么和我算的不一样八成就是这种口径差异。6.2 IN 和 EXISTS语义相近侧重点不同判断某类电影是否存在票房过亿的作品两种写法都行-- IN 写法 SELECT title FROM movies WHERE movie_id IN ( SELECT movie_id FROM box_office WHERE total_wan 10000 ); -- EXISTS 写法 SELECT m.title FROM movies m WHERE EXISTS ( SELECT 1 FROM box_office b WHERE b.movie_id m.movie_id AND b.total_wan 10000 );IN的逻辑是先算出子查询结果集再逐个比对EXISTS的逻辑是对外表每一行去子查询里试一下有没有匹配找到就停。所以当外表小、子查询结果集大的时候EXISTS通常更快反之外表大、子查询结果集小的时候IN更合适。这个结论有前提MySQL 优化器在较新版本里对两者做了不少等价改写别把它当铁律背写完之后用EXPLAIN看一眼执行计划最实际。真正需要死记的是前面提过的子查询结果里可能有NULL的时候坚决不用NOT IN改用NOT EXISTS。这是会算错结果的问题不是快慢问题。6.3 相关子查询求每组第一名每个类型票房最高的那部电影是练习里的高频难题因为它不能简单用GROUP BY加MAX解决——MAX能给你最高票房数字但给不出对应的片名。相关子查询的解法是这样SELECT m.title, m.genre, b.total_wan FROM movies m JOIN box_office b ON b.movie_id m.movie_id WHERE b.total_wan ( SELECT MAX(b2.total_wan) FROM movies m2 JOIN box_office b2 ON b2.movie_id m2.movie_id WHERE m2.genre m.genre );关键是最后那句m2.genre m.genre——子查询引用了外层的m.genre所以它不能独立执行必须对外表每一行各跑一次。这就是它慢的原因外表有多少行子查询就跑多少次。数据几万行以内感觉不到上百万行就是灾难。顺带提醒一下这个写法的隐患如果某个类型有两部电影票房完全相同且都是最高两条都会返回。这算不算错取决于业务定义要做严格只取一条就得再加去重逻辑。6.4 用窗口函数重写的思路同样的问题换个写法性能和可读性都能上一个台阶SELECT title, genre, total_wan FROM ( SELECT m.title, m.genre, b.total_wan, RANK() OVER (PARTITION BY m.genre ORDER BY b.total_wan DESC) AS rk FROM movies m JOIN box_office b ON b.movie_id m.movie_id ) t WHERE rk 1;PARTITION BY负责切块ORDER BY负责块内排序RANK给出名次。这个思路的优势是把排名这个动作显式表达出来比相关子查询那种用相等反推名次的写法直观得多。RANK和ROW_NUMBER的区别在于并列处理并列第一都保留用RANK只留一条用ROW_NUMBER。写排行榜的时候这两个选错结果会差出好几行。7. 排序分页与结果自查7.1 排序不稳定是结果看着随机的元凶ORDER BY total_wan DESC如果存在并列值MySQL 不保证并列行之间的顺序而且换个执行计划顺序就变了。分页场景下这会导致经典问题第一页看到的某条记录翻到第二页又出现一次或者干脆消失了。解决方法是加唯一键兜底ORDER BY total_wan DESC, movie_id ASC LIMIT 10 OFFSET 0;movie_id唯一加入之后排序完全确定分页就稳了。这条经验在真实项目里几乎是必踩的坑尤其在按热度排序 分页这种场景下用户刷新两次看到重复内容八成就是排序不稳定。7.2 LIMIT 的偏移写法与第 N 高LIMIT 10 OFFSET 20和LIMIT 20, 10等价前者可读性更好。需要注意的是深分页性能LIMIT 100000, 10并不是跳过十万行而是取出十万零十行再扔掉前面十万行越往后越慢。优化方式是用游标式的写法记住上一页最后一个movie_id下一页写WHERE movie_id 上次的值 LIMIT 10。查票房第二高的电影这类题写法有两种-- 写法一排序加偏移并列情况可能出错 SELECT title FROM movies m JOIN box_office b ON b.movie_id m.movie_id ORDER BY b.total_wan DESC LIMIT 1 OFFSET 1; -- 写法二先去重再取第二并列安全 SELECT DISTINCT total_wan FROM box_office ORDER BY total_wan DESC LIMIT 1 OFFSET 1;第一种写法在两部片子票房相同时第二高会变成并列第一的另一部语义就变了。所以题目里只要出现第二高第 N 高先想清楚它指的是排名第 N 的记录还是第 N 大的数值答案不一样。7.3 结果对不上时的排查顺序我固定按这个顺序排查基本能在五分钟内定位问题步骤查什么典型发现1把SELECT换成COUNT(*)单跑主表主表行数和预期是否一致2逐步加JOIN每加一次看行数变化行数暴涨说明产生笛卡尔积3去掉GROUP BY看明细明细里就能看到意外值4把HAVING挪成WHERE试一遍报错说明条件依赖聚合5单独跑子查询看结果集是否返回多行、是否含NULL第 2 步尤其重要。很多人一次性写完四表连接结果不对就不知道从哪下手。加一个JOIN看一次行数问题出在哪一段立刻暴露。第 5 步是我查NOT IN问题最快的路径——子查询里只要冒出一个NULL答案就必然是空的。我在这套练习里还养成了一个习惯复杂的查询用两条独立的简单查询交叉验证。比如算每个类型的平均票房我先用GROUP BY算一遍再挑一个类型单独WHERE genre 悬疑算一次平均值两个数对上才算完。这个做法看着笨但比事后被问这个数怎么来的要高效得多。最后分享一个小技巧写带GROUP BY的查询时我习惯先把SELECT里所有非聚合列抄下来逐个数一遍——它们是不是都在GROUP BY里或者是不是都被聚合函数包住了。这一步三十秒能挡掉后面半小时的报错排查。
