IN子查询不支持多列结果，必须返回单列；应改用EXISTS实现多条件匹配，或通过字段拼接转为单列，且需注意子查询为空时WHERE恒为假。
IN 子查询里不能直接用多列结果
很多人写 SELECT * FROM orders WHERE (user_id, status) IN (SELECT user_id, status FROM users)，直接报错。MySQL 和 PostgreSQL 都不支持这种「行构造器 + 多列子查询」的写法（除非子查询明确返回单列）。错误信息通常是 Operand should contain 1 column(s)。
根本原因是 IN 左侧是单值或单列列表，右侧子查询必须返回**恰好一列**，哪怕你逻辑上想比对组合键。
- ✅ 正确：用
IN匹配单字段，比如id IN (SELECT id FROM blacklist) - ❌ 错误：写成
(a,b) IN (SELECT a,b FROM t)（多数数据库不认） - ⚠️ 特殊：PostgreSQL 支持行语法
(a,b) IN (VALUES (1,'x'), (2,'y'))，但不支持嵌套子查询返回多列
用 EXISTS 替代多条件匹配更安全
当你要判断某条记录是否“存在于另一个复杂查询结果中”，尤其是涉及多个字段关联时，EXISTS 是更可靠、语义更清晰的选择。
例如：查出所有「订单用户状态为 VIP 且最近 30 天有登录」的订单：
SELECT o.*
FROM orders o
WHERE EXISTS (
SELECT 1
FROM users u
WHERE u.id = o.user_id
AND u.level = 'VIP'
AND u.last_login >= CURRENT_DATE - INTERVAL '30 days'
);
-
EXISTS不关心子查询返回什么值，只看是否能匹配到一行，性能通常优于IN（尤其子查询结果大时） - 子查询中必须关联外层表（如
u.id = o.user_id），否则变成无意义的常量判断 - 避免在
EXISTS子查询里写SELECT *—— 用SELECT 1更轻量
真要硬用 IN，得把多列转成单列哈希或拼接
如果业务强依赖 IN 语法（比如 ORM 自动生成、权限过滤模块），又必须比对组合条件，可以手动构造唯一标识。
常见做法是拼接字段（注意处理 NULL）：
-- MySQL 示例：用 CONCAT_WS 避免 NULL 导致整个结果为 NULL
SELECT * FROM orders
WHERE CONCAT_WS('|', user_id, status) IN (
SELECT CONCAT_WS('|', user_id, status)
FROM users
WHERE role = 'admin'
);
- 拼接符（如
|）必须确保不会出现在原始字段值中，否则可能误匹配 - PostgreSQL 推荐用
COALESCE显式处理 NULL：COALESCE(user_id::text, 'NULL') || '|' || COALESCE(status, 'NULL') - 拼接方案在大数据量下无法走索引，性能会明显下降，仅适用于中小结果集
IN 子查询结果为空时的行为容易被忽略
当右侧子查询没返回任何行，比如 SELECT id FROM config WHERE key = 'disabled_users' 查不到数据，那么整个 IN 表达式结果就是 FALSE（不是 NULL，也不是跳过判断）。
这意味着：WHERE id IN (SELECT ...) 在子查询无结果时，**整条 WHERE 条件恒为假，查询返回空集** —— 这和直觉可能相反，特别是当你期望“没配置就不过滤”时。
- 想实现“无配置则不限制”，得显式加判断：
WHERE NOT EXISTS (SELECT 1 FROM config WHERE key = 'disabled_users') OR id IN (SELECT id FROM config WHERE key = 'disabled_users') - 或者改用左连接 + IS NULL 判断，逻辑更直观
- 这个细节在动态权限、灰度开关等场景里极易引发线上问题
