MySQL 8.0+原生支持COUNT(DISTINCT col1, col2)，而PostgreSQL、SQL Server等数据库不支持该语法，因其将DISTINCT视为单值修饰符；PostgreSQL需用COUNT(DISTINCT (col1, col2))行构造器，SQL Server则必须用子查询SELECT COUNT(*) FROM (SELECT DISTINCT col1, col2 FROM t) AS tmp。
为什么 COUNT(DISTINCT col1, col2) 在 MySQL 里能用，但在 PostgreSQL 和 SQL Server 里报错？
因为标准 SQL 不支持 COUNT(DISTINCT col1, col2) 这种多列写法——只有 MySQL（8.0+）和 SQLite 原生支持。PostgreSQL、SQL Server、Oracle 都会直接抛出 ERROR: syntax error at or near "," 或类似提示。
本质是：这些数据库把 DISTINCT 当作单值修饰符，不接受元组级去重语义。MySQL 是特例，它把 (col1, col2) 解析为一个复合表达式，等价于 COUNT(DISTINCT CONCAT(col1, '\0', col2)) 的逻辑（内部实现细节不同，但效果一致）。
- 别硬套 MySQL 写法到其他数据库，否则查不到结果还报错
- PostgreSQL 用户可改用
COUNT(DISTINCT (col1, col2))（注意括号必须存在，且是行构造器语法） - SQL Server 必须用子查询或
GROUP BY+COUNT(*)替代
在 PostgreSQL 中正确统计 (user_id, action_type) 的唯一组合数
PostgreSQL 支持行构造器，所以最简方案就是加一层括号：
SELECT COUNT(DISTINCT (user_id, action_type)) FROM events;
注意：(user_id, action_type) 是一个匿名行（row value），不是普通字段列表。漏掉外层括号就会报错。
- 如果字段含 NULL，
(NULL, 'click')和(NULL, 'view')被视为不同组合，符合预期 - 性能上，PostgreSQL 会对整行做哈希去重，大表时建议在
(user_id, action_type)上建联合索引 - 不能写成
COUNT(DISTINCT user_id, action_type)—— 这会被解析为两个独立参数，语法错误
SQL Server 或 Oracle 怎么安全实现等效逻辑？
必须绕过语法限制，用子查询生成唯一组合再计数：
SELECT COUNT(*) FROM (SELECT DISTINCT user_id, action_type FROM events) AS unique_pairs;
这是跨数据库最兼容的写法，所有主流引擎都支持。
- 子查询别名
unique_pairs在 SQL Server 中不可省略，否则报Incorrect syntax near ')' - Oracle 12c+ 可用
SELECT COUNT(*) FROM (SELECT user_id, action_type FROM events GROUP BY user_id, action_type)，效果相同但更啰嗦 - 大数据量时，
GROUP BY子句可能比DISTINCT略快（取决于优化器和索引），但差异通常可忽略
什么时候 COUNT(DISTINCT ...) 会悄悄少算？
核心陷阱是 NULL 处理：所有数据库中，DISTINCT 会把包含 NULL 的整行/元组当作未知值，**不参与去重比较**。比如：
user_id | action_type --------|------------ 1 | 'click' 1 | NULL 1 | 'click'
上面三行在 MySQL/PostgreSQL 中，COUNT(DISTINCT (user_id, action_type)) 返回 2（(1,'click') 和 (1,NULL)），但如果你本意是“只要 user_id 相同就合并”，那就错了。
- 确认业务逻辑是否允许 NULL 参与去重；若不允许，先用
COALESCE(user_id, -1), COALESCE(action_type, 'unknown')做标准化 - MySQL 对
(NULL, NULL)和(NULL, 'x')视为不同，和其他数据库一致，不存在特殊兼容问题 - 没有银弹：多字段去重的本质是定义“什么算重复”，得先对齐业务语义，再选语法
