直接JOIN多对多表后SUM/COUNT必然翻倍，因数据库仅做行级拼接而不逻辑去重：一个用户关联3个标签、2篇文章，JOIN后生成3×2=6行，SUM(article_views)即累加6次；这不是bug，是关系代数的必然行为。
为什么直接 JOIN 多对多表后 SUM/COUNT 一定翻倍
因为数据库只做行级拼接，不做逻辑去重。一个用户关联 3 个标签、2 篇文章，LEFT JOIN user_tag 再 LEFT JOIN articles 就会生成 3×2=6 行；SUM(article_views) 就在这 6 行上累加，结果是真实值的 6 倍——这不是 bug，是关系代数的必然行为。
验证是否已膨胀：执行 SELECT user_id, COUNT(*) FROM users u LEFT JOIN user_tag ut ON u.id = ut.user_id GROUP BY user_id，若某 user_id 出现多次，说明已膨胀。
必须用子查询预聚合，且别名、类型、键必须严格一致
预聚合不是“优化技巧”，是避免统计错误的刚性步骤。漏掉任一条件都会报错或结果错乱：
-
MySQL报Error Code: 1248. Every derived table must have its own alias→ 子查询缺AS t - 字段类型不一致（如主表
id是VARCHAR，中间表user_id是BIGINT）→ 索引失效，JOIN 变全表扫描 -
ON u.id = t.user_id中字段名不匹配（比如写成u.id = t.uid）→ 返回空结果，且无提示 -
WHERE is_active = 1写在外层WHERE→LEFT JOIN实质退化为INNER JOIN，未打标用户彻底消失
正确写法示例（统计每个用户的活跃标签数 + 最新文章发布时间）：
SELECT u.id, u.name,
COALESCE(t.tag_count, 0) AS tag_count,
a.latest_post
FROM users u
LEFT JOIN (
SELECT user_id, COUNT(*) AS tag_count
FROM user_tag
WHERE is_active = 1
GROUP BY user_id
) AS t ON u.id = t.user_id
LEFT JOIN (
SELECT user_id, MAX(created_at) AS latest_post
FROM articles
GROUP BY user_id
) AS a ON u.id = a.user_id;
需要明细字段时，子查询预聚合不够用，得换 LATERAL 或窗口函数
当你要的不只是“数量”或“最大值”，而是“最新那条记录的完整字段（比如 title 和 status）”，子查询预聚合就无法满足——它只返回聚合结果，丢掉了原始行。
此时应切换策略：
- PostgreSQL / MySQL 8.0+：用
LATERAL子查询，确保每主表行只取一条从表记录 - 所有支持窗口函数的数据库：用
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)标序，外层WHERE rn = 1 - 避免在同一个
SELECT中混用聚合函数和窗口函数（如SUM(x), AVG(y) OVER (...)），多数数据库直接报错
例如取每个用户的最新文章标题：
SELECT u.id, u.name, a.title, a.created_at FROM users u LEFT JOIN LATERAL ( SELECT title, created_at FROM articles WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1 ) AS a ON true;
UNION ALL 合并多张同构表再聚合，不是 JOIN 的替代方案
有人想用 UNION ALL 把 user_tag_2025 和 user_tag_2026 合并后再 GROUP BY，这可行，但要注意：
-
UNION ALL是纵向堆叠，列数、顺序、类型必须完全一致，否则报错 - 不能写成
SELECT COUNT(*) FROM t1 UNION ALL SELECT COUNT(*) FROM t2—— 这是两个标量结果合并，不是表合并 - 真正写法是：
SELECT user_id, COUNT(*) FROM (SELECT user_id FROM t1 UNION ALL SELECT user_id FROM t2) AS u GROUP BY user_id - 如果各分表已有索引，
UNION ALL后再聚合仍比跨表JOIN更快；但若要关联用户姓名等主表字段，仍需额外JOIN users
最易被忽略的一点：预聚合后的子查询，哪怕只查一张表，也必须建好索引。没索引的 GROUP BY user_id 在百万级中间表上会退化为全表扫描，性能崩盘比写错 JOIN 类型还快。
