mysql 5.7及更早版本报error 1241是因为解析器将distinct视为单值修饰符，只允许count(distinct col)单列表达式；多列写法count(distinct col1, col2)被解析为多操作数而直接拒绝，属语法硬限制而非功能缺失。
MySQL 5.7 及更早版本报 ERROR 1241 是因为语法解析器不支持多列
MySQL 在 8.0.22 之前把 DISTINCT 当作单值修饰符，只允许后面跟一个表达式。写成 COUNT(DISTINCT col1, col2) 会被解析器直接拒绝，抛出 ERROR 1241 (21000): Operand should contain 1 column(s)。这不是功能缺失，而是旧版 SQL 解析逻辑的硬性限制。
验证方式很简单：SELECT COUNT(DISTINCT 'a', 'b'); 在 MySQL 5.7 中必然报错；在 8.0.22+ 中能返回 1。
- 升级不是万能解法：部分生产库仍运行在兼容模式或受限于中间件（如某些分库分表代理），即使 MySQL 版本够高，也可能被拦截
-
SELECT VERSION();是第一步，但不能代替实际执行测试 - 别依赖文档说“支持”，一定要在目标环境跑一句
SELECT COUNT(DISTINCT 1, 2);
PostgreSQL 和 SQL Server 报 syntax error at or near "," 是因标准语义冲突
SQL 标准中 DISTINCT 作用于行（row），而聚合函数参数要求是标量表达式。PostgreSQL 和 SQL Server 严格遵循这一点，因此 COUNT(DISTINCT col1, col2) 被视为传了两个参数，语法非法。
它们各自提供了替代路径：
- PostgreSQL 支持
COUNT(DISTINCT (col1, col2))—— 注意外层括号是必须的，表示行构造器（row constructor） - SQL Server 完全不支持任何形式的多列
DISTINCT在COUNT()中，只能用子查询 - Oracle 同样拒绝该写法，且不提供行构造器等效语法，必须走
SELECT COUNT(*) FROM (SELECT DISTINCT ...)
SQLite 和 Hive 的“不支持”是设计取舍而非版本问题
SQLite 声称支持 COUNT(DISTINCT col1, col2)，但行为与其他引擎不一致：它实际按字段列表逐个去重再笛卡尔积，语义错误。Hive 则从语法层就禁用，连解析都不通过，报 ParseException: cannot recognize input near 'DISTINCT' ','。
这意味着你无法靠“试一下”来跨库复用 SQL：
- Hive 用户必须改写为子查询，且注意 Hive 2.x+ 才支持子查询别名，
AS tmp不可省略 - SQLite 中哪怕写对了，结果也可能和 MySQL/PostgreSQL 对不上，尤其当存在 NULL 或重复单列值时
- 任何含 Hive 或 SQLite 的混合查询场景（如 Spark SQL 兼容 Hive 语法），都应默认禁用多列
DISTINCT写法
拼接方案（CONCAT + 分隔符）看似通用，实则埋雷最多
用 COUNT(DISTINCT CONCAT(col1, '|', col2)) 绕过语法限制，是新手最常选的“兼容方案”，但它在数据层面不可靠：
- 分隔符出现在原始数据里就会导致碰撞：比如
col1 = 'a|b'和col2 = 'c'拼成'a|b|c'，与col1 = 'a'、col2 = 'b|c'结果相同 -
CONCAT遇到任意NULL返回NULL，整行丢失，且无法区分是数据为空还是拼接失败 - 字符串长度超限（如 MySQL 默认
GROUP_CONCAT_MAX_LEN=1024）会静默截断，去重结果错误但无提示 - 类型隐式转换陷阱：数值
1和字符串'1'拼接后都是'1'，语义混淆
真正跨库安全的底线写法只有这一种：SELECT COUNT(*) FROM (SELECT DISTINCT col1, col2 FROM t WHERE ...) AS tmp。别省那层子查询，也别幻想“加个 MD5 就万事大吉”。
