MySQL中LIMIT和OFFSET必须写在GROUP BY、HAVING、ORDER BY之后，作用于分组后的结果集；错误顺序会报语法错，且无ORDER BY时分页结果不可靠。
MySQL 直接用 LIMIT + OFFSET 就行，但必须写在 GROUP BY 之后
MySQL 允许在 GROUP BY 后直接跟 LIMIT 和 OFFSET，语法最简，但容易忽略执行顺序导致出错。
-
LIMIT作用对象是分组后的结果集，不是原始行 —— 所以它必须出现在GROUP BY、HAVING、ORDER BY之后 - 错误写法：
SELECT ... FROM table GROUP BY x LIMIT 10 OFFSET 0 WHERE y=1——WHERE不能放后面，会报语法错 - 正确顺序：WHERE → GROUP BY → HAVING → ORDER BY → LIMIT/OFFSET
- 示例：
SELECT customer_id, SUM(amount) AS total FROM sales GROUP BY customer_id ORDER BY total DESC LIMIT 20 OFFSET 40
SQL Server 必须用子查询或 CTE，否则 OFFSET 报错
OFFSET ... FETCH 在 SQL Server 中不接受裸 GROUP BY 查询，必须套一层子查询并加别名，否则报 Incorrect syntax near 'OFFSET'。
- 子查询必须有别名（如
AS grouped），否则解析失败 -
ORDER BY必须引用外层列名（如total_sales），不能写SUM(amount)这类表达式 - 相同聚合值会导致分页跳行 —— 建议加二级排序，比如
ORDER BY total_sales DESC, category - 兼容老版本（2005/2008）？改用
ROW_NUMBER()：子查询里加ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC, SUM(amount) DESC) AS rn，外层WHERE rn BETWEEN 21 AND 30
需要总数时，别用 COUNT(*) 直接包 GROUP BY
前端分页常需总页数，但 SELECT COUNT(*) FROM (SELECT ... GROUP BY ...) t 在大数据量下性能差，且 MySQL 8.0+ 之前不支持窗口函数优化。
- 错误做法：
SELECT COUNT(*) FROM (SELECT customer_id FROM sales GROUP BY customer_id) t—— 全量分组再计数，IO 和 CPU 开销大 - 更优解：单独跑一次轻量聚合统计，例如
SELECT COUNT(DISTINCT customer_id) FROM sales（前提是分组字段无 NULL 或业务允许近似） - 如果必须精确且数据稳定，可缓存分组总数到应用层或 Redis，避免每次查
- 注意：MySQL 的
SQL_CALC_FOUND_ROWS已弃用，不要依赖
多字段分组 + 分页时，ORDER BY 容易漏掉稳定性保障
按 country, age 分组后分页，若只写 ORDER BY COUNT(*) DESC，相同计数的组在不同页可能重复或遗漏。
- 根本原因：SQL 标准不保证无明确排序依据时的行序稳定性
- 必须补全所有分组字段做二级排序，例如
ORDER BY COUNT(*) DESC, country, age - 如果分组字段含 NULL，MySQL 默认把 NULL 放前面，SQL Server 放后面 —— 跨数据库迁移时行为不一致
- 测试方法：手动改
OFFSET值，对比第 1 页和第 2 页交界处是否有重复或缺失的(country, age)组合
ORDER BY 子句都得想清楚“当值相同时，靠什么确保下一页不跳”；别名、执行顺序、NULL 处理这些细节，一漏就导致线上分页错乱。 
