DISTINCT无法解决关联导致的“逻辑重复”，因其按整行去重，订单关联多条明细时因item_name不同仍返回多行；应先聚合从表再关联，或用窗口函数取首行。
为什么 DISTINCT 有时压根不解决重复问题
因为 DISTINCT 是对整行做去重，只要任意一列值不同，就视为不同行。常见于主表一条记录关联从表多条时——比如一个订单有 3 条订单项，SELECT DISTINCT order_id, item_name FROM orders o JOIN order_items i ON o.id = i.order_id 会返回 3 行，order_id 看似重复，但每行的 item_name 不同，整行就不重复。
这时候加 DISTINCT 没用，反而掩盖了真实的数据结构问题。
- 先确认重复是「逻辑冗余」还是「关联爆炸」：查出重复行，看哪些字段变、哪些不变
- 如果只想取每个订单的任意一条明细，别用
DISTINCT，改用ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY id)配合子查询过滤 - MySQL 8.0+、PostgreSQL、SQL Server 都支持窗口函数；老版本 MySQL 只能靠相关子查询或临时变量模拟
用 GROUP BY 过滤时，SELECT 列必须是分组键或聚合列
这是语法硬约束，不是风格建议。写 SELECT order_id, customer_name FROM orders o JOIN order_items i ON o.id = i.order_id GROUP BY order_id 在大多数数据库里直接报错，因为 customer_name 既没在 GROUP BY 里，也没套 MAX()/MIN() 等聚合函数。
错误提示通常是：column "customer_name" must appear in the GROUP BY clause or be used in an aggregate function。
- 想保留非分组字段？用
MAX(customer_name)或ANY_VALUE(customer_name)（MySQL 5.7+ 开启sql_mode=ONLY_FULL_GROUP_BY后需显式使用） - PostgreSQL 和 SQL Server 不允许
ANY_VALUE，必须明确聚合逻辑；若字段值在组内恒定，可放心用MIN()/MAX() -
GROUP BY本质是降维操作，它不“过滤重复”，而是按维度折叠数据——理解这点才能避免滥用
关联前先聚合从表，比关联后去重更可控
当目标只是获取每个订单的统计信息（如总金额、商品种类数），最稳的写法是：先对 order_items 按 order_id 聚合，再和 orders 关联。这样既避免笛卡尔积，又让语义清晰。
SELECT o.order_id, o.customer_name, i.total_amount, i.item_count FROM orders o JOIN ( SELECT order_id, SUM(price * qty) AS total_amount, COUNT(*) AS item_count FROM order_items GROUP BY order_id ) i ON o.id = i.order_id
- 性能上通常优于
GROUP BY大宽表，尤其从表数据量远大于主表时 - 不会因从表中存在 NULL 或空字符串导致分组异常（比如
GROUP BY order_id, remark中remark为 NULL 的行可能被意外拆成多组） - 如果还需展示某一条明细（如“首件商品名称”），在子查询里加
STRING_AGG(item_name, ',') LIMIT 1或用FIRST_VALUE(item_name) OVER (PARTITION BY order_id ORDER BY created_at)
警惕 DISTINCT ON（PostgreSQL）和 TOP 1 WITH TIES（SQL Server）的隐含排序依赖
这两个语法看似简洁，但结果强依赖 ORDER BY。比如 SELECT DISTINCT ON (order_id) order_id, item_name FROM order_items ORDER BY order_id, created_at DESC，表示“每个 order_id 取最新一条”。但如果漏写 ORDER BY，PostgreSQL 会报错；而 SQL Server 的 WITH TIES 必须配合 TOP 和确定性排序，否则行为不可预测。
-
DISTINCT ON只在 PostgreSQL 有效，其他数据库不兼容 - 即使写了
ORDER BY，也要确认排序字段在业务上是否真的唯一（比如两个商品同一秒创建，created_at相同，DISTINCT ON可能随机选其一） - 生产环境慎用无主键/无索引字段排序，容易触发全表扫描
实际遇到重复，先别急着加 DISTINCT 或 GROUP BY，花 30 秒看看执行计划里有没有 Hash Join 扫出几百倍行数——那大概率是关联方式或条件写错了，而不是去重没到位。
