ThinkPHP 6 的 paginate() 遇 GROUP BY 报错，根本原因是 MySQL 5.7+ 默认启用 ONLY_FULL_GROUP_BY 模式，而 paginate() 内部自动执行的 COUNT(*) 查询不含 GROUP BY，与分组逻辑冲突；必须通过 countQuery 参数手动提供基于分组的总组数查询，如用子查询或 COUNT(DISTINCT field) 确保返回单值，且与主查询共享 WHERE 条件、不带 ORDER BY 或非聚合字段。
ThinkPHP 6 的 paginate() 遇到 GROUP BY 直接报错怎么办
不是代码写错了，是 MySQL 5.7+ 默认开启 ONLY_FULL_GROUP_BY 模式，而 ThinkPHP 分页内部会自动执行一个不含 GROUP BY 的 COUNT(*) 查询来算总条数——这个 COUNT 查询和你前面的分组逻辑冲突，MySQL 拒绝执行整条语句。
常见错误现象：SQLSTATE[HY000]: General error: 1055 Expression #1 of SELECT list is not in GROUP BY clause，哪怕你 ->group('user_id') 写得完全正确也会触发。
- 别在
paginate()前直接链式调用->group()，90% 场景会失败 - 必须显式绕过默认 COUNT，用
countQuery参数手动提供分组后的总组数 -
countQuery必须返回一个只含单字段（如COUNT(*)）的结果集，且 SQL 要和主查询逻辑一致（比如都带相同WHERE条件）
手写 countQuery 的正确写法
核心是：让 count 查询只统计“有多少个组”，而不是“有多少条原始记录”。它必须和主查询共享过滤条件，但不能带非聚合字段或 ORDER BY。
示例（查每个用户的订单数并分页）：
立即学习“PHP免费学习笔记（深入）”；
$countQuery = Db::name('order')
->field('COUNT(DISTINCT user_id) as total')
->where($where); // $where 是你主查询用的条件数组
$list = Db::name('order')
->field('user_id, COUNT(*) as cnt')
->where($where)
->group('user_id')
->order('cnt DESC')
->paginate([
'list_rows' => 10,
'count_query' => $countQuery,
]);
-
COUNT(DISTINCT user_id)比COUNT(*)更准确，避免 JOIN 后重复计数 -
count_query中不要出现ORDER BY、LIMIT、非聚合字段，否则 MySQL 可能报错或结果不准 - 如果主查询用了
JOIN，countQuery也得 JOIN，但只保留用于去重或计数的关联表，避免膨胀
原生 PHP + MySQL 实现分组分页时的 COUNT 陷阱
不用框架时，很多人直接写两个 SQL：SELECT COUNT(*) FROM orders GROUP BY user_id —— 这是错的，MySQL 不允许这样返回多行给 COUNT。
真正要的是“分组后有多少组”，所以 COUNT 查询必须是标量结果：
SELECT COUNT(*) FROM (
SELECT user_id FROM orders WHERE status = 1 GROUP BY user_id
) AS _grouped;
- 子查询封装是安全做法，确保外层 COUNT 返回单值
- 主查询分页用
LIMIT时，OFFSET仍按“组序号”计算，不是原始行号 - 如果要取每组最新一条记录（比如每个用户最近下单时间），
GROUP BY本身做不到，得换窗口函数或关联子查询，和分页逻辑解耦处理
为什么不能关掉 ONLY_FULL_GROUP_BY
临时改 sql_mode 看似能跑通，但掩盖了真实问题：你的 SELECT 字段语义模糊。比如 SELECT user_id, name FROM orders GROUP BY user_id，MySQL 不知道该返回哪条 name —— 是第一条？最后一条？随机一条？结果不可控。
- 线上环境禁用该模式等于埋雷，不同 MySQL 版本/配置下行为可能突变
- 分组分页的本质是“聚合视图分页”，不是“原始数据分页”，字段选择必须严格对应分组维度或聚合函数
- 一旦业务需要扩展（比如加筛选条件、跨表统计），没走
countQuery或子查询封装的写法几乎必然重构
COUNT(DISTINCT ...) + countQuery；后者就得放弃 GROUP BY，改用窗口函数或两次查询，分页逻辑也得重设计。 
