Hacker News 上一篇题为《Postgres SELECT DISTINCT 无法扩展》的文章引发技术社区讨论。文章指出，PostgreSQL 的 SELECT DISTINCT 语句在处理大规模数据时存在性能瓶颈，难以满足高负载场景的扩展需求。评论区内，用户 DiabloD3 确认了这一结论，指出 DISTINCT 在执行时会先对结果进行排序，这是导致性能问题的根本原因，且该行为已在 PostgreSQL 官方文档中有详细说明。不过他同时质疑原文作者可能不了解 GROUP BY 这一替代方案、索引优化以及 ANALYZE 统计命令，并提到 PostgreSQL 18 新引入的跳过扫描（Skip Scan）索引技术或能缓解此类问题。另一位用户 Dylan16807 随即反驳：原文已明确说明跳过扫描对该场景并无帮助；索引优化在文中被多次提及，作者也分析过查询执行计划，因此针对原作者缺乏基础知识的批评难以成立。这场讨论触及了数据库查询优化中的多个核心议题：DISTINCT 与 GROUP BY 的语义与性能差异、排序操作的成本、索引设计策略，以及查询规划器如何在不同执行路径之间做出选择。
事件分析
SELECT DISTINCT 与 GROUP BY 的性能取舍是数据库领域长期存在的话题：DISTINCT 为保证去重正确性通常依赖排序或哈希聚合，在列基数高、数据量大的场景下开销陡增，这也是其被指’无法扩展’的技术根源。PostgreSQL 18 引入的跳过扫描原本旨在优化 B-tree 索引中前导列重复值的扫描效率，能否覆盖去重场景取决于查询规划器的路径选择与统计信息质量。此次争论也暴露出社区认知分歧：一方认为此类问题应通过文档学习与基础教学解决，另一方则主张数据库内核应对语义等价的查询模式进行自动改写与优化。若后续版本能在规划器层面识别 DISTINCT 与 GROUP BY 的等价性并择优执行，此类争议有望从源头减少。
核心观点：SQL 语法越简洁越易隐藏性能陷阱，DISTINCT 之争本质是执行成本与表达便利的权衡，懂规划器比堆砌技巧更重要。
原文链接：Hacker News
