我前两天跟一个做数据分析的朋友聊天，他吐槽说公司新来的实习生写SQL，为了去重动不动就甩个 DISTINCT 上去，结果数据量一大，查询慢得像蜗牛爬。这事儿让我想起自己刚入行那会儿，也曾把 DISTINCT 当成万能钥匙，看到重复数据就想用它来清理。其实，DISTINCT 这个关键字，用好了是神器，用不好就是给自己挖坑。它背后的逻辑并不复杂，就是告诉数据库“给我返回不重复的行”，但你真的理解它是怎么工作的么？
DISTINCT 最基础的用法，就是跟在 SELECT 后面，把查询结果中完全相同的行合并成一行。比如你有个员工表，想看看有哪些不同的部门，写 SELECT DISTINCT department FROM employees，数据库就会把部门字段里的所有重复值去掉，只返回唯一的部门名称。这个过程看似简单，但数据库内部要做的事可不少——它需要把所有数据先扫描一遍，然后对结果进行排序或哈希处理，才能识别出哪些行是重复的。数据量小的时候，比如几百条记录，几乎感受不到延迟；可一旦到了几十万甚至上百万条，那种全表扫描加排序的成本，就能让查询从秒级变成分钟级。
我见过太多人把 DISTINCT 当成默认操作来用。有一次，一个同事写了个查询，要从订单表里找出所有下过单的客户 ID，他直接写 SELECT DISTINCT customerid FROM orders。这个表有 500 万条记录，跑一次要 40 多秒。后来我建议他看看 customerid 字段上有没有索引，结果发现根本没建索引。加了索引后，同样的查询变成了 0.3 秒。原因很简单：如果涉及的字段有索引，数据库可以利用索引的有序性快速去重，根本不需要把整张表的数据都拖出来排序。索引就像书的目录，你不需要翻遍整本书才能找到不重复的章节。
另一个常见的坑是 DISTINCT 和多个字段搭配使用。很多人以为 SELECT DISTINCT col1, col2 会分别对 col1 和 col2 去重，实际上它是把 col1 和 col2 组合成一个整体，然后对这个组合去重。比如你有个销售表，想看看每个区域卖过哪些产品，写 SELECT DISTINCT region, product FROM sales，返回的是每个区域和产品的唯一组合，而不是分别列出不同的区域和不同的产品。这个区别很微妙，搞错了就会得到完全不同的结果。我有个前同事就因为这个误解，在周报里给老板展示了一张满是重复行的表格，被点名批评了一整个下午。
说到性能优化，DISTINCT 还有个不太被注意的细节：它跟 ORDER BY 搭配时，可能会触发额外的排序操作。很多数据库在执行 DISTINCT 时，默认就会对结果进行排序，因为排序是去重最直接的方式之一。如果你再显式加上 ORDER BY，等于让数据库重复劳动。更高效的做法是，如果不需要排序，就用 GROUP BY 代替 DISTINCT，语义更明确，优化器对 GROUP BY 的处理往往更成熟。比如 SELECT customerid FROM orders GROUP BY customerid， 在大多数数据库里，这个查询的执行计划会比 DISTINCT 版本更优，尤其是在有合适索引的情况下。
DISTINCT 的另一个变种是 COUNT(DISTINCT …) ，用来统计不重复值的数量。这个操作看似无害，但性能开销非常大，因为它需要先对指定字段去重，再计数，这个过程通常无法充分利用索引的快速统计能力。我做过测试，在一个 200 万行的表上跑 COUNT(DISTINCT userid)，用时 8 秒多；而如果先为 userid 建索引，再跑同样的查询，时间降到 0.5 秒。所以，如果经常需要统计某个字段的不重复值数量，最好的做法是提前建好索引，或者考虑用物化视图、缓存等手段来优化。
还有一点容易被忽略：DISTINCT 作用于 NULL 值。SQL 标准中，NULL 代表未知或缺失，多个 NULL 在去重时会被视为相同。所以 SELECT DISTINCT status FROM orders 如果 status 里有很多 NULL，最终结果只会出现一个 NULL。这个行为有时符合预期，有时却会让人困惑。比如你想统计所有不同的订单状态，包括状态为空的订单，DISTINCT 会给你一个 NULL 行，但你无法区分这个 NULL 对应一条记录还是上万条记录。这时，如果需要更精细的控制，可以考虑用 GROUP BY 配合聚合函数，或者用窗口函数 ROW_NUMBER() 实现更灵活的去重逻辑。
说一点个人体会：DISTINCT 是数据库提供的便利工具，但它不是银弹。写 SQL 时，多问自己一句“我真的需要去重吗？有没有更高效的方法？”很多时候，重复数据的产生是因为数据模型设计不合理，或者查询逻辑本身有缺陷。比如发现某个查询结果总是有重复行，与其在查询末尾加个 DISTINCT 强行去重，不如回去检查表之间的连接条件是否写漏，或者是否该用 LEFT JOIN 的地方用了 INNER JOIN。把问题消灭在源头，比事后用 DISTINCT 擦屁股要优雅得多。数据库不是用来乱造的工具，你对它多一份理解，它就会还你一份效率。
