DISTINCT 去重的是整行而非单列，JOIN 一对多时因关联字段差异导致"看似重复实则不同"；应优先用 EXISTS/IN、GROUP BY 或 ROW_NUMBER() 精准控制去重逻辑。为什么 DISTINCT 加了还是有重复？不是 DISTINCT 不管用，而是它去重的是整行结果------只要任意一列值不同，就算"不重复"。多表 JOIN 后，一对多关系（比如一个订单对应多个商品）天然会把主表记录"撑开"，此时哪怕你只选主表字段，数据库仍按连接后的中间结果去重，ORDER_ID 看似一样，但因关联的 ITEM_ID、QUANTITY 等字段参与了 JOIN，整行实际不同。实操建议：先确认重复根源：用 SELECT * 查看原始 JOIN 结果，观察哪几列在变如果只需要主表数据，优先考虑 EXISTS 或 IN 替代 JOIN，避免物理拼接DISTINCT 必须紧贴 SELECT，不能写成 SELECT DISTINCT a.* FROM ...（MySQL 8.0+ 支持，但多数旧版本报错）用 GROUP BY 替代 DISTINCT 更可控GROUP BY 明确指定按哪些列聚合，比 DISTINCT 更易预测行为，也方便后续加聚合函数（如统计子项数量）。但它要求所有 SELECT 中的非分组字段必须用聚合函数包裹，否则报错（SQL 标准严格模式下）。常见错误现象：SELECT order_id, customer_name, COUNT(*) FROM orders o JOIN items i ON o.id = i.order_id GROUP BY order_id ------ customer_name 未出现在 GROUP BY 且没聚合，MySQL 5.7+ 默认拒绝执行。实操建议：只选主表关键字段时，GROUP BY 列和 SELECT 列保持一致，例如 SELECT o.id, o.status FROM orders o JOIN ... GROUP BY o.id, o.status需要附带子表信息（如最新一条日志），改用窗口函数 ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY created_at DESC) 过滤注意 GROUP BY 性能：字段越多、数据量越大，临时表和排序开销越高LEFT JOIN + IS NULL 检查缺失关联时别误伤主表想查"没关联到子表的主表记录"，常写 LEFT JOIN ... WHERE sub.id IS NULL。但如果子表有多条匹配记录，LEFT JOIN 仍会产生多行，再用 WHERE 过滤时逻辑没问题，但容易忽略：若子表本就允许空值或存在重复键，IS NULL 可能匹配出意料之外的行。使用场景：排查订单无支付记录、用户无头像等"缺失"类问题。 RedClaw 百度推出的手机端万能AI Agent助手
相关推荐
User_芊芊君子几秒前
sbt 鸿蒙 PC 适配全记录：从 JVM 构建工具到 HAP_HNP 交付闭环小范的技术工坊1 分钟前
每日一题gogogo野生技术架构师5 分钟前
Redis Hot Key 与 Big Key：危害、发现与解决方案杨云龙UP21 分钟前
DB2 HADR 主备架构活动日志参数优化操作手册杨女士YRJ24 分钟前
python+pytest+01我是大猴子26 分钟前
MyBatis‑Plus & MyBatis‑Flex 区别鸽芷咕31 分钟前
Mu Editor 鸿蒙 PC 适配全记录：用 Qt 与嵌入式 CPython 重建教学型 Python IDE鸽芷咕33 分钟前
SQL Server数据库迁移避坑指南：老代码不用重写，金仓KES V9R4C019把路铺平了鸽芷咕35 分钟前
MongoDB 鸿蒙 PC 适配全记录：从 Bazel 交叉编译到 HNP 原生数据库服务YangYang9YangYan40 分钟前
2026 校招管理会计 JD 拆解，数据分析能力要求与工具清单