视图含 distinct 时优化器无法展开合并，因去重破坏确定性，导致谓词无法下推、索引失效、强制物化及排序/哈希开销；而 group by 语义明确，更易被优化。
视图定义含DISTINCT时，优化器无法展开合并
因为视图只是SQL语句的封装，数据库执行时会尝试把视图“内联展开”成原始查询，再统一优化。但一旦视图里写了 DISTINCT，优化器就基本放弃这个动作——它没法保证外层查询加 WHERE、JOIN 或 LIMIT 后，去重逻辑仍与原意一致。
典型表现是：调用视图时加了 WHERE a = 'x'，本该走 a 上的索引，结果 EXPLAIN 显示 type: ALL、Using temporary。这不是索引失效，而是优化器压根没把谓词下推进视图内部，先物化了整个 DISTINCT 结果集，再过滤。
-
DISTINCT触发隐式排序或哈希，中间结果不可预测，优化器不敢做等价改写 - MySQL/PostgreSQL 遇到视图含
DISTINCT，默认走TEMPTABLE算法，强制物化，切断所有下推路径 - 哪怕外层只
LIMIT 1，也得先把视图里全部去重结果算出来，再截断
DISTINCT让视图失去“确定性”，阻断优化器推理
优化器依赖确定性行为做计划重用和谓词传递。而 DISTINCT 的语义本身不保证顺序、不承诺行数、对 NULL 处理模糊（两个 NULL 不被视为相等），这让优化器无法安全地做列裁剪、索引选择或连接顺序调整。
比如视图定义为 SELECT DISTINCT id, name FROM users，你在外层加 WHERE id = 123，优化器不能假设 id 在去重后仍能用上主键索引——因为 DISTINCT 可能已触发全表扫描+排序，id 的有序性被破坏。
- 视图中含
DISTINCT+ORDER BY，MySQL 5.7 直接报错；8.0+ 虽允许，但排序字段若不在DISTINCT列表里，会被忽略 -
NULL值在去重时被跳过比较，导致优化器无法准确估算基数，常误判为高选择性而选错索引 - 如果底层表字段类型不一致（如
user_id INTvslog.user_id VARCHAR），DISTINCT还会放大隐式转换开销，进一步干扰优化器决策
为什么GROUP BY视图反而更容易被优化
语义上 SELECT DISTINCT a,b FROM t 和 SELECT a,b FROM t GROUP BY a,b 等价，但优化器对后者更友好。因为 GROUP BY 显式表达了分组意图，支持键值消除、并行聚合、索引下推等成熟路径。
例如，当 a,b 上有联合索引时，GROUP BY a,b 可直接利用索引顺序避免排序；而 DISTINCT 即使面对同样索引，MySQL 8.0+ 也仅在单表场景下启用哈希聚合，一碰 JOIN 就退化。
-
GROUP BY允许后续追加聚合函数（如MIN(updated_at)），优化器可将聚合下推到底层表 -
DISTINCT视图无法在外层再套COUNT(*)或SUM()，语法直接报错 - 某些国产库（如金仓 V9R4C19）会对
DISTINCT自动重写为GROUP BY，但这是特例，不是通用行为
真正该检查的不是“能不能消除”，而是“有没有必要用DISTINCT”
绝大多数带 DISTINCT 的视图，本质是开发为掩盖语义不清的查询逻辑。比如想按公司名去重，却写了 SELECT DISTINCT company, id, created_at FROM orders——由于 id 和 created_at 几乎总不同，实际根本不去重。
这种写法不仅让优化器束手无策，还把性能隐患固化在视图定义里，每次调用都重复执行无效去重。比优化器是否消除更关键的，是回归业务需求：你要的是“每组一条记录”，还是“整行唯一”？前者该用窗口函数，后者才考虑 DISTINCT。
- 视图里
DISTINCT+ 主键字段 = 白跑一趟，整行天然不重复 - 含
TEXT、JSON或多列组合的DISTINCT，极易触发磁盘临时表，响应时间从毫秒跳到秒级 - 如果必须保留某类冗余字段（如时间戳），优先用
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)替代，既可控又可索引
