distinct去不掉重复数据的根本原因是其作用于整行而非单列，若select中包含唯一字段（如主键、时间戳）或join产生笛卡尔积，即使业务上“看起来重复”也会被视作不同行；应根据需求选用group by或窗口函数精准控制去重逻辑。
为什么 DISTINCT 有时去不掉重复数据？
根本原因不是 DISTINCT 失效，而是你 SELECT 的字段组合本身就不重复——哪怕业务上“看起来一样”。比如查 users 和 orders 表，用了 SELECT DISTINCT u.id, u.name, o.order_id，只要任意一个 order_id 不同，整行就算不同。
- 检查是否无意中带入了唯一字段（如主键、时间戳、自增ID），这是最常见陷阱
-
DISTINCT作用于整行结果，不是按某列“逻辑去重” - 如果只想按用户去重，但又要显示订单信息，
DISTINCT就不合适，得换思路
用 GROUP BY 替代 DISTINCT 控制去重维度
当你要“按某几列去重”，同时保留其他列的聚合信息（比如最新订单、订单总数），GROUP BY 是更可控的选择。
- 必须把“去重依据列”全写进
GROUP BY，其他非聚合列不能裸露在SELECT中（MySQL 5.7+ 严格模式会报错：Expression #3 of SELECT list is not in GROUP BY clause） - 想取每个用户的最新订单？用
MAX(o.created_at)或配合子查询/窗口函数 - 示例：只取每个用户的最早一条订单记录
SELECT u.id, u.name, MIN(o.created_at) AS first_order FROM users u JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.name;
嵌套查询里 DISTINCT 放错位置导致无效
很多人把 DISTINCT 塞在外层 SELECT，但内层 JOIN 已经产生笛卡尔积，外层再 DISTINCT 只是“亡羊补牢”，性能差还可能漏逻辑问题。
- 优先在最靠近数据源的位置控制连接方式：确认
JOIN条件是否精确，有没有漏加关联条件 - 如果多对多关系（如用户-标签-文章），先用子查询或 CTE 把中间关系“压平”再 JOIN
- 避免在含
LEFT JOIN的查询里盲目加DISTINCT——它可能掩盖了本该用EXISTS或IN替代的逻辑
真正要“去重展示”，往往该用窗口函数而不是 DISTINCT
当你需要“每个用户只显示一条订单，且是最新那条”，DISTINCT 和 GROUP BY 都难兼顾“取完整行 + 按条件筛选”。这时 ROW_NUMBER() 更直接。
- 注意数据库兼容性：
ROW_NUMBER()在 MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持，但旧版 MySQL 不行 - 排序必须明确：没
ORDER BY的窗口函数行为不可靠 - 别忘了过滤：窗口函数只是编号，最终还得用
WHERE rn = 1取出目标行
SELECT id, name, order_id, created_at
FROM (
SELECT u.id, u.name, o.order_id, o.created_at,
ROW_NUMBER() OVER (PARTITION BY u.id ORDER BY o.created_at DESC) AS rn
FROM users u
JOIN orders o ON u.id = o.user_id
) t
WHERE rn = 1;
实际业务里，“重复”常是建模或连接逻辑的问题，不是 SQL 关键字能一键修好的。尤其在多层嵌套、带汇总计算或权限过滤的查询里，先理清“到底要哪一行”，再决定用 DISTINCT、GROUP BY 还是窗口函数——选错工具，后面调半天性能也白搭。
