结论是表关联时数据虚增的根本原因在于关联逻辑未对齐业务语义，尤其当被关联表存在一对多关系却未做去重或聚合时，JOIN会自动笛卡尔展开；解决方式是在关联前用ROW_NUMBER()等窗口函数明确控制每组仅保留一行，而非依赖DISTINCT或GROUP BY事后补救。
直接说结论：表关联时出现数据虚增，根本原因不是“重复记录本身”，而是关联逻辑没对齐业务语义——尤其是当被关联表存在一对多关系却没做去重或聚合时，JOIN 会自动笛卡尔展开。解决它不靠“先删重再关联”，而靠在关联前明确控制每组保留哪一行。
为什么 LEFT JOIN 一加重复数据就翻倍？
常见现象：LEFT JOIN 后行数远超左表，SUM 或 COUNT 结果明显偏高。这不是 bug，是 SQL 的标准行为：只要右表某组有 N 条匹配记录，左表对应行就会被复制 N 次。
- 典型场景：订单主表
orders关联订单明细order_items，但误用客户表customers（含历史变更记录）做JOIN - 关键陷阱：没意识到
customers表里同一customer_id可能有多条记录（比如地址更新、状态变更） - 后果：一个订单关联出 3 条客户记录 → 在聚合时被算作 3 笔订单
用 ROW_NUMBER() 在 JOIN 前截断重复
核心思路：不删除物理数据，只让关联时每组最多取 1 行。窗口函数是最可控的方式，尤其适合“保留最新/最早/指定规则”的场景。
- 示例：从
customers中为每个customer_id只取updated_at最新的那条 WITH latest_customer AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) AS rn FROM customers) SELECT o.*, c.name FROM orders o LEFT JOIN latest_customer c ON o.customer_id = c.customer_id AND c.rn = 1;- 注意：
AND c.rn = 1必须写在ON条件里，不能放WHERE，否则会把左表没匹配上的行也过滤掉 - 性能提示：
PARTITION BY字段和ORDER BY字段最好有联合索引，否则ROW_NUMBER()可能全表排序
DISTINCT 和 GROUP BY 在关联后补救的局限性
很多人习惯先 JOIN 再 SELECT DISTINCT 或 GROUP BY，但这治标不治本，且容易掩盖问题。
-
SELECT DISTINCT order_id, customer_name看似去重，但若原始关联产生 10 行相同order_id+customer_name，只是合并成 1 行，丢失了其他字段（比如不同地址、不同电话） -
GROUP BY order_id配合MAX(customer_name)会强制选一个值，但无法保证选的是业务上正确的那条（比如最新地址） - 更隐蔽的问题：如果后续还要
SUM(amount)，而amount来自明细表，DISTINCT会把金额也去重，导致求和错误
真正要检查的三个地方
虚增不是语法问题，是建模和语义问题。动手写 SQL 前，必须确认：
- 关联字段是否真的构成业务上的“一对一”？比如
customer_id在客户表里是不是天然唯一？如果不是，就要定义“哪个才是当前有效记录” - 被关联表有没有自然主键？如果没有，
ROW_NUMBER()的ORDER BY就得依赖业务字段（如created_at、is_active），不能随便用id - 是否需要保留重复背后的业务信息？比如客户多次修改邮箱，可能需统计修改次数——这时不该去重，而该用
COUNT(*) OVER (PARTITION BY customer_id)单独计算
最常被跳过的一步：没确认“重复”在业务上到底代表什么。是脏数据？还是历史快照？处理方式天差地别。
