视图出现重复记录是因为底层查询未去重，而非视图本身问题；根本原因在于创建视图时未使用 distinct 或窗口函数等去重逻辑，需根据需求选择 distinct 或 row_number() 等方案。
视图里出现重复记录，本质是底层查询没去重
视图本身不存储数据，它只是保存了一条 SELECT 语句。所以当你查视图发现重复，问题一定出在创建视图时的查询逻辑里——不是视图“没去重”，而是你根本没写 DISTINCT 或等效逻辑。
常见诱因包括：
- 建视图时直接
SELECT *或选了带自然重复的字段组合（比如SELECT user_id, order_time FROM orders，同一用户一天多单就必然重复） - 用了
JOIN但没处理一对多关系（如用户表左连订单表，一个用户有 3 条订单，视图就返回 3 行） - 误以为
GROUP BY在视图里能“自动去重”，却忘了它必须配合聚合函数，否则 MySQL 8.0+ 会因ONLY_FULL_GROUP_BY报错
用 DISTINCT 创建去重视图最直接
只要目标是“结果行唯一”，DISTINCT 就是最轻量、最明确的选择。它作用于整行，只有所有选定列值完全一致才算重复。
正确写法示例：
CREATE VIEW unique_user_locations AS SELECT DISTINCT user_id, city, province FROM user_profiles;
注意这些细节：
-
DISTINCT必须紧贴SELECT后，不能写成SELECT user_id, DISTINCT city - 如果只想按
user_id去重，但又想顺带返回最新地址，DISTINCT无能为力——得换ROW_NUMBER()窗口函数 -
NULL被视为相同值，DISTINCT会把多行user_id=123, city=NULL合并为一行
需要保留某一条（如最新/最小ID）时别硬套 DISTINCT
当重复行之间有主键、时间戳或优先级差异，而你只想留一条代表记录，DISTINCT 会失效。例如：
- 用户表和登录日志表关联后，每个用户对应多条登录记录，你想只取最后一次登录的 IP 和时间
- 商品表有多条同
sku记录，但price和updated_at不同，要取最新价格
这时必须用窗口函数，典型结构：
CREATE VIEW latest_user_logins AS
WITH ranked AS (
SELECT user_id, ip, login_time,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC) AS rn
FROM login_logs
)
SELECT user_id, ip, login_time
FROM ranked
WHERE rn = 1;
关键点：
-
PARTITION BY user_id定义分组维度，ORDER BY login_time DESC决定哪条排第一 - 不能把
ROW_NUMBER()放进视图的外层SELECT，否则排序逻辑丢失；必须用 CTE 或子查询包裹 - MySQL 8.0+、PostgreSQL、SQL Server 都支持，但 SQLite 不支持窗口函数，需换
GROUP BY + MAX()模拟
DISTINCT 性能不好？先看是不是真瓶颈
很多人一看到“视图慢”就怀疑 DISTINCT，其实多数情况是冤枉的：
- 小表（DISTINCT 几乎无感；真正卡住的是大数据量 + 多长文本字段（如
VARCHAR(2000)），因为排序/哈希成本飙升 - 如果视图被高频调用，且去重逻辑固定，可考虑物化：MySQL 不原生支持物化视图，但可用定时任务把
SELECT DISTINCT ...结果写入一张新表，再让视图查这张表 - 更常见的性能陷阱其实是没索引——对
DISTINCT涉及的字段建联合索引（如(city, province)），能让去重从全表扫描变成索引扫描
最后提醒一句：视图定义一旦发布，应用代码就依赖它的输出结构。如果某天你把 DISTINCT 加进已有视图，可能让下游 ORDER BY 报错（因为 ORDER BY 字段必须出现在 SELECT 列表里），这点比去重逻辑本身更易被忽略。
