视图中加DISTINCT仅对视图输出结果去重，无法防止JOIN或聚合导致的重复，且不保证排序和分页有效性；应优先用GROUP BY明确分组逻辑，或用窗口函数精准取最新记录。
视图里加 DISTINCT 能去重，但不是万能解法
SQL 视图本身不存储数据，只是保存查询逻辑，所以 DISTINCT 在视图定义里起作用的前提是：它被真正执行到了最终结果集上。常见误区是以为只要在视图里写了 DISTINCT，下游所有查询就自动“干净”了——其实不然。
比如你建了一个视图：
CREATE VIEW user_orders AS SELECT DISTINCT user_id, order_id FROM orders;它确实能返回去重后的行，但一旦外部查询再加
JOIN 或聚合（如 COUNT(*)），重复可能重新出现，因为 DISTINCT 只作用于视图的“输出快照”，不约束后续操作。
- 视图中用
DISTINCT本质是把去重逻辑固化进定义，适合封装“唯一组合”类需求（如用户-设备绑定关系） - 如果底层表有主键或唯一约束，优先考虑用
GROUP BY显式控制去重维度，比DISTINCT更可控 -
DISTINCT在视图里会隐式影响执行计划，某些数据库（如 MySQL 5.7）可能拒绝在含DISTINCT的视图上做UPDATE，PostgreSQL 则允许但需满足可更新性条件
什么时候该用 GROUP BY 替代 DISTINCT 写视图
当你需要去重的同时保留其他字段的聚合信息（比如取最新时间、统计次数），DISTINCT 就不够用了——它只能原样返回“看起来不同”的行，无法处理“同一组里选哪一条”的问题。
例如：要查每个用户的最近一次登录记录，不能只靠 DISTINCT user_id，必须按 user_id 分组，并用 MAX(login_time) 或窗口函数定位最新行。
-
GROUP BY更明确地表达了“按什么分组、对哪些列聚合”，语义比DISTINCT清晰 - 在 SQL Server 或 PostgreSQL 中，含
GROUP BY的视图默认不可更新；MySQL 对简单GROUP BY视图支持有限，需检查information_schema.VIEWS中的IS_UPDATABLE - 如果只是为去重而用
GROUP BY（比如GROUP BY a, b不带聚合函数），性能通常和DISTINCT接近，但可读性和维护性更好
DISTINCT 在多表 JOIN 视图里的陷阱
这是最常踩坑的地方：视图定义里写了 DISTINCT，但底层 JOIN 导致笛卡尔积，DISTINCT 是最后才生效的，意味着数据库得先算出全部组合，再过滤——性能差，还可能掩盖逻辑错误。
比如：
CREATE VIEW user_profiles AS SELECT DISTINCT u.id, u.name, a.city FROM users u LEFT JOIN addresses a ON u.id = a.user_id;如果一个用户有 5 条地址，这句就会先生成 5 行，再靠
DISTINCT 压成 1 行，但你根本不知道 city 取的是哪一条。
- 优先用
LEFT JOIN ... ON ... AND ...加条件限制关联范围，或改用LATERAL（PostgreSQL）/APPLY（SQL Server）只取一条关联记录 - MySQL 8.0+ 支持
ROW_NUMBER() OVER (PARTITION BY u.id ORDER BY a.updated_at DESC)配合子查询，比DISTINCT更精准 - 别依赖
DISTINCT来“修复”设计不当的关联逻辑——它只是补丁，不是方案
视图去重后，下游 ORDER BY 和分页为什么经常失效
很多同学发现视图里加了 ORDER BY，但调用时排序还是乱的。这是因为标准 SQL 规定：视图定义中的 ORDER BY 除非配合 TOP 或 LIMIT，否则会被忽略。更麻烦的是，加上 DISTINCT 后，数据库可能重排行序以优化去重过程，导致你预设的顺序完全不可靠。
- 必须在查询视图的外部语句里写
ORDER BY，且排序字段得在视图 SELECT 列表中显式出现 - 分页（
LIMIT/OFFSET）一定要放在最外层，否则DISTINCT+ORDER BY组合在不同数据库行为不一致（如 PostgreSQL 允许视图内排序，MySQL 直接报错） - 如果业务强依赖顺序，建议在视图里加一个确定性排序字段（比如
MIN(created_at)），而不是依赖原始行序
DISTINCT 精确覆盖——多数时候，它只是个表层手段，背后的数据关系和一致性约束，才是容易被忽略的复杂点。 
