distinct 可用于视图定义，但必须紧随 select 后、禁止独立 order by；其作用于整行而非单字段，无法替代正确建模或实现按业务规则去重，且导致视图不可更新。
DISTINCT 能直接用在视图定义里，但必须放对位置、避开 ORDER BY，且后续基本不能更新
创建含 DISTINCT 的视图时语法不能错
视图本质是保存的 SELECT 语句，DISTINCT 是合法修饰符，但有硬性约束：
-
DISTINCT必须紧跟在SELECT后面，不能写成SELECT name, DISTINCT email - 整个视图定义中不能出现独立的
ORDER BY，比如CREATE VIEW v AS SELECT DISTINCT name FROM users ORDER BY name在 SQL Server 和 PostgreSQL 中直接报错；MySQL 5.7+ 虽允许创建，但排序会被忽略 - 如果真需要排序，得配合
LIMIT（MySQL/PostgreSQL）或TOP（SQL Server），例如SELECT DISTINCT name FROM users ORDER BY name LIMIT 10
视图里用 DISTINCT 后，为什么查出来还是重复？
常见错觉：以为加了 DISTINCT 就万无一失。实际问题往往出在理解偏差：
-
DISTINCT作用于整行，不是单个字段——SELECT DISTINCT name, email去重依据是(name, email)组合，哪怕name相同但email不同，也会保留两行 - 如果基表本身有隐藏差异（如空格、大小写、NULL vs 空字符串），
DISTINCT会把它们当不同值处理 - 多表
JOIN后未显式限制关联逻辑，容易因一对多关系放大行数，此时DISTINCT只能“擦屁股”，不能替代正确建模
想按业务规则去重（比如留最新一条），DISTINCT 不够用
DISTINCT 没有优先级概念，只认“值是否完全相同”。要实现“每组取最新/最小/非空”的逻辑，必须换方案：
- 用窗口函数：比如
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC)标记序号，外层WHERE rn = 1 - 用
GROUP BY配合聚合：如SELECT user_id, MAX(create_time) FROM orders GROUP BY user_id，但会丢失其他字段 - 把去重逻辑下推到子查询或 CTE，而不是硬塞进视图——尤其当去重要求随参数变化（如按时间范围动态过滤）时，视图反而僵化
真正容易被忽略的点：视图加了 DISTINCT 后，多数数据库会直接标记为不可更新。哪怕底层是单表，只要结果集无法一一映射回原行（DISTINCT 天然破坏这个前提），UPDATE 或 DELETE 视图就会失败。别等上线后才发现报表页面的编辑功能全崩了。
