count(*)在left join后总是1是因为它统计分组内行数，左表每行必保留（右表无匹配则补null行）；要统计右表实际匹配数须用count(右表非空字段)，如count(o.id)。
LEFT JOIN后COUNT(*)为什么总是1
因为COUNT(*)统计的是分组内的行数，不是“右表有几条匹配记录”。LEFT JOIN保证左表每行都保留，哪怕右表没匹配，也会生成一行（右表字段全为NULL），COUNT(*)照样计为1。
要统计“右表实际有多少条”，必须用COUNT(右表非空字段)，比如COUNT(o.id)或COUNT(o.order_no)——这些字段为NULL时会被COUNT自动忽略。
- 业务想体现“0订单用户”，就写
COUNT(o.id) - 想统计“该部门总共关联了几行数据”（含空行），才用
COUNT(*)，但这种需求极少 - 别用
COUNT(1)替代，它和COUNT(*)行为完全一致，不能解决语义混淆问题
GROUP BY字段漏写或写错表前缀就报错
MySQL 5.7+ 和 PostgreSQL 默认开启ONLY_FULL_GROUP_BY，要求SELECT列表里所有非聚合字段，必须显式出现在GROUP BY子句中。
常见错误：SELECT d.name, u.age, COUNT(*) FROM dept d JOIN user u ON d.id = u.dept_id GROUP BY d.id —— u.age既没聚合也没分组，直接报错。
- 补全
GROUP BY d.id, d.name, u.age（仅当u.age在组内唯一，否则逻辑错） - 改用聚合表达式：
MAX(u.age)或ANY_VALUE(u.age)（MySQL支持，PostgreSQL不认ANY_VALUE） - 多表同名字段（如
id）必须加前缀：GROUP BY d.id，不能只写GROUP BY id -
GROUP BY里不能用SELECT中的列别名（如d.name AS dept_name），得写原始字段d.name
WHERE条件放错位置会让LEFT JOIN退化成INNER JOIN
把右表过滤条件写在WHERE里，比如WHERE o.status = 'paid'，数据库会先完成JOIN，再过滤——此时左表无匹配的行已被WHERE筛掉，LEFT JOIN语义失效。
正确做法是把条件挪进ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。这样未匹配或状态不符的右表行仍被视作“空”，左表行得以保留。
- 左表过滤（如
u.is_active = 1）可以放心放WHERE - 右表时间、状态等高选择性条件，优先下推到
ON或子查询中 - 若用子查询预过滤右表，写法是：
LEFT JOIN (SELECT * FROM orders WHERE status = 'paid') o ON u.id = o.user_id
性能卡在百万级中间结果集，不是索引问题而是执行路径错了
查慢不是因为没建索引，而是JOIN发生在WHERE和GROUP BY之前，导致数据库先把全部订单和用户拼出来（比如100万行），再过滤、再分组。
看EXPLAIN里的rows值：如果JOIN后GROUP BY前的行数比最终分组数高几个数量级（如100万→800），说明冗余数据已加载，索引救不了。
- 把强过滤条件（如时间范围、状态）下推到子查询：
JOIN (SELECT * FROM orders WHERE created_at > '2026-06-01') o ON ... - 明细表（如订单）优先预聚合：
JOIN (SELECT user_id, COUNT(*), SUM(amount) FROM orders GROUP BY user_id) co ON ... - 确保
GROUP BY字段顺序匹配联合索引顺序，例如按users.region, users.level分组，索引就得是INDEX(region, level)，而非INDEX(level, region)
真正难的不是写对语法，是判断哪部分数据该早筛、哪部分该晚算——中间结果集大小，永远比索引覆盖更关键。
