LEFT JOIN后COUNT(*)总是1是因为它统计的是连接后每行（含右表NULL行），而非右表有效记录数；应改用COUNT(右表非空字段)并配合COALESCE确保0值，一对多时须预聚合明细表再JOIN。
LEFT JOIN后COUNT(*)为什么总是1
因为LEFT JOIN保证左表每行至少出现一次，哪怕右表没匹配，这行也计入结果集——COUNT(*)统计的是“行数”，不是“右表有效记录数”。你看到的1，是这一行本身被计数，不是业务意义上的“有1笔订单”。
真正该用的是COUNT(orders.id)或COUNT(orders.created_at)：这些字段在无匹配时为NULL，COUNT()自动跳过，返回0。想让无订单用户显示为数字0，必须写COALESCE(COUNT(o.id), 0)。
-
COUNT(*)和COUNT(1)行为完全一致，别指望后者能绕过NULL陷阱 - 别用
COUNT(orders.status)——如果该字段允许NULL，会漏掉有效但状态为空的记录 - 若右表主键未定义为
NOT NULL，优先选orders.id（主键天然非空）而非其他字段
GROUP BY字段必须带表前缀且补全所有非聚合列
多表有同名列（比如id、name）时，GROUP BY id是非法的——数据库无法判断你要按哪张表分组，MySQL 8.0+ 和 PostgreSQL 直接报错。
SELECT里所有非聚合字段（如u.name、u.city）必须显式出现在GROUP BY中，否则ONLY_FULL_GROUP_BY模式下直接拒绝执行。这不是语法错误，是数据库强制要求结果确定性。
- 正确写法：
GROUP BY u.id, u.name, u.city（假设u是users表别名） - 错误写法：
GROUP BY id、GROUP BY users.id（别名未定义）、GROUP BY u.name AS username（别名不能用于GROUP BY） - 如果
SELECT里用了表达式（如DATE(o.created_at)），GROUP BY里也得一模一样，不能只写o.created_at
ON里写过滤条件，别放WHERE
对右表字段加WHERE（如WHERE o.status = 'paid'）会让LEFT JOIN退化为INNER JOIN——没匹配的左表行会被整行过滤掉，失去“保留主表全量”的语义。
要保留左表全部记录，同时只关联“已支付”订单，条件必须挪到ON里：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。
-
ON决定“怎么连”，WHERE决定“连完筛谁” - 时间范围、状态码、类型标识等右表业务过滤，一律放在
ON子句末尾 - 左表自身的过滤（如
WHERE u.status = 'active'）可以放心放WHERE，它不影响JOIN逻辑
一对多关联导致SUM/COUNT虚高怎么办
一个用户关联3笔订单 + 2个地址 → JOIN后变成6行 → GROUP BY u.id再SUM(o.amount)会把同一笔订单重复加2次（因地址膨胀）。这不是GROUP BY写错了，是JOIN阶段数据就撑开了。
根本解法是预聚合：先对明细表按外键汇总，再JOIN主表。中间结果集大幅缩小，避免笛卡尔积干扰业务语义。
- 错误写法：
FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN addresses a ON u.id = a.user_id GROUP BY u.id - 正确写法：用子查询或CTE先聚合，例如
(SELECT user_id, COUNT(*) AS order_cnt FROM orders GROUP BY user_id)，再LEFT JOIN到users - 预聚合后性能通常提升一个数量级，且
SUM、COUNT值不再虚高
EXPLAIN里的rows和key_len，就直接优化SQL；或者本地MySQL关了ONLY_FULL_GROUP_BY跑通了，上线PostgreSQL直接报错。 
