每个人都可以，
拥有SSL证书

DISTINCT 用的地方其实挺多，但大多数人只拿它做单字段去重。真到了要多字段去重的场景，第一反应往往是绕道去写子查询或者 Group By，其实 DISTINCT 自己就能扛下来，只是很多人没搞清楚它背后到底怎么判重的。

先讲原理，其实不复杂。SELECT DISTINCT 后面跟了多个字段的时候，数据库不是把每个字段单独去重，而是把这一整行指定的字段当成一个组合去比对，只有这几个字段的值完全一致才被当重复。这个点我第一次理解反了，以为它会把每一列各自去重一遍再拼回来，结果查出来的行数和预期对不上，折腾半天才知道是组合去重。

举一个实际例子。

假设有一张员工表 employees，字段里有 first_name、last_name、department，表里故意塞了几条完全重复的记录，还有两条 first_name 是 NULL 的。

CREATE TABLE employees (
    id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    department VARCHAR(50),
    position VARCHAR(50)
);

INSERT INTO employees VALUES
(1, '张', '伟', 'HR', 'Manager'),
(2, '王', '芳', 'IT', 'Developer'),
(3, '张', '伟', 'HR', 'Manager'),  -- 重复记录
(4, '李', '娜', 'Finance', 'Analyst'),
(5, '王', '芳', 'IT', 'Developer'),  -- 重复记录
(6, '赵', '明', 'IT', 'Developer'),
(7, NULL, '刘', 'HR', 'Assistant'),  -- 包含NULL值
(8, NULL, '刘', 'HR', 'Assistant');  -- NULL值重复记录

SELECT DISTINCT
    first_name,
    last_name,
    department
FROM
    employees
ORDER BY
    COALESCE(first_name, '') || ' ' || last_name;

上面这种写法，DISTINCT 后面把要去重的字段列全，剩下的就交给数据库。结果是一组唯一的组合，重复的直接消失，两条 NULL 的也会被合并成一条。

这里想说一个容易踩的坑，就是 NULL 的处理。大多数数据库会把多个 NULL 当成同一个值看待，所以那两条 first_name 为 NULL 的记录会被去重成一条。

如果你心里的预期是 NULL 之间也该算作不同，那就别指望数据库帮你区分，得自己另外处理，比如用 COALESCE 或 IFNULL 先把 NULL 替换成别的东西再进判断。

还有排序。ORDER BY 里要用到这些字段时得小心，因为 first_name 可能是 NULL，直接按它排会把 NULL 顶到最前面，看着很别扭。

像上面那样用 COALESCE 先把 NULL 换成空串再拼接排序就顺眼多了。这种小坑平时数据少的时候根本不会暴露，等线上数据多起来，顺序一乱你才知道当时少想了一步。

实际使用里还有几点值得提醒。

一个是性能，多字段 DISTINCT 有时候挺费资源的，尤其表很大的时候，最好在前面加个 WHERE 把范围先圈小，不然全表扫一遍再组合去重，慢起来人都麻了。再一个是数据库差异，不同数据库对 NULL 的处理和字符串连接语法不完全一样，MySQL 和 SQL Server 的拼接写法就不同，换库的时候一定要记得检查一下。

索引这块也可以顺手做掉。如果去重查询是常态，给常用字段建一个对应的索引，能省不少事，别等着慢查询出来了再去补。

顺带说个题外话。要是你把这种查询接口做成了内部小工具，想挂到公网上让同事在线查一下数据，那就绕不开给自己服务配一个 HTTPS 证书。我这边用的是 lcjmSSL，免费申请，支持泛域名和 IP 证书，而且自动申请、自动验证、自动续期，配好之后基本不用再管，比自己手动去生成 CSR、上传验证文件省心太多。它底层走的还是 Let's Encrypt 那套 ACME 流程，证书的可信度完全不是问题。

说到底，多字段去重没多玄乎，记住组合去重这一个点，再处理好 NULL 和排序，基本就不会翻车了。