视图中使用 distinct 并非语法错误，但会显著增加执行计划复杂度，易导致全量去重、多次回表及隐式排序；应先检查基表索引与视图定义，再通过 explain 对比展开sql与视图查询的执行计划，重点优化索引覆盖与字段顺序。
视图里用 DISTINCT 不是语法错误，但几乎必然放大执行计划复杂度——尤其当视图被嵌套调用、或上层再加 JOIN/WHERE 时，数据库很难下推过滤条件，最终导致全量去重+多次回表。
先确认是不是视图在“代人受过”
很多性能问题表面看是视图慢，实际是基表没索引、或视图定义本身触发了隐式排序。别急着改视图，先做两件事：
- 用
pg_get_viewdef('your_view')（PostgreSQL）或sp_helptext 'your_view'（SQL Server）把视图展开，拿到原始 SQL - 对这个原始 SQL 手动加
EXPLAIN，再对“从视图查”的语句也加EXPLAIN，对比两者是否生成相同执行计划；若不同，说明优化器没把视图内联，DISTINCT就被迫在最后阶段执行 - 重点看
EXPLAIN输出里有没有Using filesort或Using temporary——这是DISTINCT没走索引的铁证
给 DISTINCT 字段建覆盖索引，不是普通单列索引
DISTINCT a, b 和 DISTINCT a 的索引策略完全不同：前者必须用联合索引，且字段顺序要和 SELECT 中一致；后者单列索引即可。但光有索引还不够，得让它“覆盖”。
- 如果视图写的是
SELECT DISTINCT status, category FROM orders，就建INDEX(status, category)，不是INDEX(category, status) - 如果查询还带
WHERE create_time > '2026-01-01'，而你又常这么用，索引就得扩展为INDEX(create_time, status, category)，让 WHERE + DISTINCT 一起走索引 - 避免在
DISTINCT字段里混入大字段（如TEXT、JSON），否则索引体积暴涨，甚至无法创建；真需要展示大字段，改成先DISTINCT出主键，再用主键JOIN回原表取详情
SQL Server 视图加 SCHEMABINDING 后，DISTINCT 可能被绕过
加了 WITH SCHEMABINDING 的视图，在满足严格条件下（基表有主键、无非确定性函数、无 GETDATE() 等），SQL Server 允许你在它上面建唯一聚集索引——这时 DISTINCT 逻辑其实由索引结构保证，查询时可能直接跳过去重步骤。
- 但注意：一旦视图里写了
DISTINCT，你就没法再给它建索引了，因为索引视图要求“结果集可预测”，而DISTINCT会干扰确定性 - 正确做法是删掉视图里的
DISTINCT，改用基表上的唯一约束 + 联合索引来保障业务层不重复，让视图只做轻量投影 - 如果必须保留
DISTINCT语义，就别强求索引视图，老实用物化方式：把视图结果定期刷到一张带主键的物理表，并在该表上建好索引
SparkSQL 视图里多个 COUNT(DISTINCT) 是“自爆式”设计
Spark 不像关系型数据库，它的视图本质是逻辑计划快照，一旦视图里包含多个 COUNT(DISTINCT col1), COUNT(DISTINCT col2)，后续所有引用该视图的查询都会继承 Expand 节点——原始数据被复制 N 倍，Shuffle 数据量爆炸。
- 临时解法：把视图拆成多个单指标子查询，用
UNION ALL或JOIN在外层合并，虽然 SQL 长一点，但每个COUNT(DISTINCT)都走独立聚合路径，避免数据膨胀 - 长期解法：用
APPROX_COUNT_DISTINCT()替代精确去重，误差率通常 - 绝对要避开的操作：在视图定义里写
SELECT DISTINCT *——Spark 会尝试对所有字段做哈希去重，内存直接 OOM
最常被忽略的一点：视图性能问题，90% 出现在“多层嵌套+上层加 LIMIT”的组合里。这时候 DISTINCT 得先算完全部再截断，完全无法下推。与其死磕视图，不如把关键中间结果物化成带索引的物理表——索引建对了，比重写十遍视图都管用。
