SQL语句的书写顺序通常看起来是SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT，但这并不是数据库内部真正处理数据的顺序。数据库会先根据FROM确定数据来源，再通过WHERE过滤原始行，之后执行GROUP BY把符合条件的行归入不同分组，接着用HAVING过滤分组结果，然后才由SELECT计算输出列，最后经过ORDER BY排序和LIMIT截断。理解这个逻辑顺序，是搞清楚LIMIT到底限制行数还是组数的关键。
当查询中存在GROUP BY时，聚合操作会把同一个分组内的多行压缩成一行。压缩完成后，结果集中的每一行不再对应用户表中的某一条原始记录，而是对应一个分组。由于LIMIT的执行位置位于GROUP BY之后、甚至在ORDER BY之后，所以它面对的数据已经不是明细行，而是已经聚合出来的组。因此LIMIT限制的是返回多少组，而不是参与分组的原始行有多少条。
如果没有GROUP BY，LIMIT当然直接限制原始结果行数。例如SELECT * FROM orders LIMIT 10会返回10条订单明细。但一旦写了GROUP BY customer_id，SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id LIMIT 10，这时LIMIT 10表示最多返回10个客户的分组统计，而不是只统计前10条订单。即使某个客户在原始表中有100条订单，也只占用一个分组名额。
从逻辑执行顺序看LIMIT的位置
SQL标准中常被提及的逻辑执行顺序可以概括为：FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT/OFFSET。这个顺序并不等于物理执行顺序，优化器可能重排某些操作，但它定义了查询语义上各个子句作用于哪个结果集。按照这个语义顺序，GROUP BY发生在LIMIT之前，这是理解“LIMIT限制组数”的核心。
可以这样理解：WHERE阶段面对的是原始行，它决定哪些行有资格进入分组。GROUP BY则把这些行按照分组键折叠，生成中间分组结果。HAVING继续过滤掉不符合条件的分组。等到SELECT把需要输出的表达式计算完成后，ORDER BY对分组结果进行排序。LIMIT在最后阶段工作，它只看到已经排序完成的一行行分组数据。因此LIMIT中的数字代表最终返回多少行，而在含有GROUP BY的查询里，最终每一行恰恰就是一个组。
这个顺序也解释了为什么LIMIT不能减少分组计算的开销。如果你写GROUP BY customer_id LIMIT 10，数据库仍然需要扫描所有满足WHERE条件的行，并且完成全部分组聚合，因为只有把所有分组都算出来、排序之后，才知道哪10个组应该被返回。LIMIT只是少传输一些结果，并不能避免对大量明细数据的读取与聚合。
用示例数据验证LIMIT限制的是组数
假设有一张订单表orders，包含id、customer_id、amount三个字段。里面数据如下：客户1有5条订单，客户2有3条订单，客户3有5条订单，客户4有2条订单。如果执行SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id ORDER BY order_count DESC LIMIT 2，返回的会是分组聚合后的前两名客户。比如客户1和客户3各有5条订单，它们可能同时出现在结果中，此时结果只有两行，但底层参与统计的订单数量是10条。
-- 创建订单表
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT NOT NULL,
amount DECIMAL(10,2) NOT NULL
);
-- 插入测试数据：客户1有5条，客户2有3条，客户3有5条，客户4有2条
INSERT INTO orders (id, customer_id, amount) VALUES
(1, 1, 100.00),
(2, 1, 150.00),
(3, 1, 200.00),
(4, 1, 120.00),
(5, 1, 180.00),
(6, 2, 90.00),
(7, 2, 110.00),
(8, 2, 130.00),
(9, 3, 210.00),
(10, 3, 240.00),
(11, 3, 260.00),
(12, 3, 230.00),
(13, 3, 250.00),
(14, 4, 80.00),
(15, 4, 95.00);
-- LIMIT 2 限制的是分组后的前2组，而不是前2条订单
SELECT customer_id, COUNT(*) AS order_count
FROM orders
GROUP BY customer_id
ORDER BY order_count DESC
LIMIT 2;
上面的查询会返回customer_id为1和3的两行，或者两者顺序对调，因为它们的order_count相同。关键点在于：虽然只返回2行结果，但数据库在聚合阶段处理了全部15条订单数据。LIMIT 2并没有告诉数据库“只拿前2条订单去分组”。如果把LIMIT误解为限制原始行数，就会以为查询只会统计前两条订单所属客户的情况，这显然是错误的。
再举一个更直观的例子。执行SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id LIMIT 2，如果不加ORDER BY，不同数据库返回的组可能不同，但返回行数最大为2。无论每个组内部包含多少条订单，返回结果只有2行。这充分说明LIMIT作用在分组结果上，而非原始明细上。
常见误区与ORDER BY的执行顺序
很多开发者第一次踩坑，是因为把LIMIT理解成“先取若干行数据再执行后面的逻辑”。实际上LIMIT几乎位于逻辑执行链的最末端，比ORDER BY还要晚。可以这样验证：SELECT customer_id, COUNT(*) FROM orders GROUP BY customer_id ORDER BY order_count DESC LIMIT 2。ORDER BY先对全部分组结果按照聚合值排序，然后LIMIT取出排序后的前2组。如果LIMIT先执行，再排序，那么结果会完全不同。
另一个误区是认为GROUP BY配合LIMIT可以优化性能。由于LIMIT不能跳过聚合，数据库仍然需要读取所有相关行并计算所有组。对于大表来说，GROUP BY + LIMIT 10可能仍然很慢。要优化这种TopN分组查询，通常需要借助索引、物化视图、窗口函数或者近似计算方案，而不是依赖LIMIT减少扫描量。
-- 窗口函数方案：先分组排名，再取每个客户分组，适合复杂TopN场景
SELECT customer_id, order_count
FROM (
SELECT customer_id,
COUNT(*) AS order_count,
ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC) AS rn
FROM orders
GROUP BY customer_id
) t
WHERE rn <= 2;
在上面的窗口函数代码中，子查询仍然先完成GROUP BY，生成所有客户分组，然后ROW_NUMBER()给每个分组编号，外层WHERE rn <= 2取前两个组。这里LIMIT换成了窗口函数过滤，但本质上还是先聚合、后筛选，这也印证了分组和截断之间的先后关系。
不同数据库中的行为差异与注意点
对于包含GROUP BY和LIMIT但没有ORDER BY的查询，MySQL、PostgreSQL、SQLite等数据库并不保证返回哪些分组。MySQL在优化器选择不同执行路径时，返回的分组可能随索引变化而不同。PostgreSQL通常按照物理读取顺序或分组实现方式返回结果，同样不具备确定性。因此生产环境中涉及TopN需求时，应该显式添加ORDER BY，否则程序可能在不同版本或数据变化后得到不稳定的结果。
MySQL中有一个容易混淆的语法是SQL_CALC_FOUND_ROWS配合LIMIT。它可以在有LIMIT的情况下计算不带LIMIT时的总行数。但需要注意，这个总行数在含有GROUP BY的查询中仍然是分组后的总组数，而不是原始明细行数。例如SELECT SQL_CALC_FOUND_ROWS customer_id, COUNT(*) FROM orders GROUP BY customer_id LIMIT 2，随后执行SELECT FOUND_ROWS()，返回值是客户分组总数，即4个客户，而不是订单明细总数15条。
另外，在MySQL 8.0及某些支持分析函数的新版本数据库中，使用窗口函数如ROW_NUMBER()、RANK()可以更精细地控制“取每组前N条”或者“取全局前N组”。但无论哪种写法，只要涉及GROUP BY，都必须先聚合得到分组结果，再施加限制条件。理解这一点能避免分页统计时出现总条数对不上、返回数据错位等问题。
如何正确实现分组分页与TopN统计
如果业务需要按组进行分页，例如每页展示10个客户的订单汇总，应该先对分组结果排序，再使用LIMIT offset, page_size。语句可以写成：SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id ORDER BY order_count DESC LIMIT 20, 10。这表示跳过前20个分组，返回第21到第30个分组。ORDER BY不能省略，否则分页顺序不稳定。
对于需要“每组取前几条明细”的场景，比如查询每个客户最近3笔订单，不能简单使用GROUP BY加LIMIT，因为LIMIT只会限制客户组数量，不会限制每个客户内部的订单条数。这时应该使用窗口函数：
-- 每个客户取最近3笔订单
SELECT customer_id, order_date, amount
FROM (
SELECT customer_id, order_date, amount,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY order_date DESC
) AS rn
FROM orders
) t
WHERE rn <= 3;
这个查询没有GROUP BY，而是用PARTITION BY模拟分组，ROW_NUMBER()为每个客户内部的订单编号，外层过滤编号小于等于3的记录。它返回的是明细行，而不是组统计行。因此如果你的业务真正需要的是明细TopN，就不要使用GROUP BY + LIMIT这种组合，否则会出现数量限制错误。
总结下来，LIMIT在含有GROUP BY的查询中限制组数，是因为查询逻辑顺序决定了聚合优先于截断。要预判LIMIT的作用对象，可以问自己：在执行LIMIT的那一刻，结果集中的一行代表什么？如果没有GROUP BY，一行是一条原始记录；如果有GROUP BY，一行是一个聚合后的分组。这个判断方法比死记硬背规则更可靠，也能帮助你在复杂SQL中快速定位问题。