多列IN子查询必须用括号包裹列组合，且左右列数、类型、顺序严格一致；MySQL 5.7及以前不支持，8.0+支持但需注意sql_mode；PostgreSQL对NULL更严格；性能差时优先用EXISTS或JOIN替代。
多列IN子查询的语法结构必须用括号包裹列组合
SQL标准中，多列IN不能写成 WHERE (a, b) IN (SELECT x, y FROM ...) 这种形式——它在PostgreSQL、Oracle、SQL Server（2022+）中合法，但在MySQL 5.7及更早、SQLite中直接报错 Operand should contain 1 column(s)。关键点是：左右两边的列数、类型、顺序必须严格一致，且整个左侧必须用括号明确标识为元组。
常见错误包括：WHERE a, b IN (SELECT x, y FROM t)（缺外层括号）、WHERE (a, b) IN (SELECT x FROM t)（列数不匹配）、或在MySQL旧版本里强行使用该语法。
- MySQL 8.0+ 支持标准多列IN，但需确认
sql_mode未启用STRICT_TRANS_TABLES等导致隐式转换失败的模式 - PostgreSQL对NULL处理更严格：若子查询任意一行的
x或y为NULL，则整行不参与匹配（即(a, b) = (x, y)在任一列为NULL时恒为UNKNOWN） - 避免在大表上无索引地使用多列IN——数据库通常无法高效利用复合索引，尤其当子查询返回大量结果时
替代方案：用EXISTS + 关联条件绕过语法限制和性能陷阱
当目标数据库不支持多列IN，或子查询结果集较大时，EXISTS往往是更可靠的选择。它把“是否存在于集合”转化为“是否存在满足关联条件的记录”，语义清晰且多数引擎能更好下推过滤条件。
例如匹配用户ID和订单状态的组合：
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.id
AND o.status IN ('shipped', 'delivered')
);
- 相比
WHERE (u.id, 'shipped') IN (SELECT user_id, status FROM orders)，EXISTS天然规避了多列IN的兼容性问题 - 如果
orders(user_id, status)上有复合索引，EXISTS可高效走索引查找；而多列IN子查询若返回万级结果，可能触发临时表或内存溢出 - 注意
EXISTS不关心子查询返回多少行，只判断存在性，因此SELECT 1比SELECT *更轻量
JOIN + 去重比IN更可控，尤其涉及聚合或分页时
当你实际需要的是“获取所有匹配维度的主表记录”，而不是纯粹布尔判断，直接JOIN再DISTINCT往往比嵌套IN更直观、更易调试。
比如查同时满足多个标签的文档：
SELECT DISTINCT d.id, d.title FROM docs d INNER JOIN doc_tags dt ON d.id = dt.doc_id WHERE dt.tag_id IN (101, 205, 307);
- 若要求“必须同时包含全部三个tag_id”，则不能用
IN，而要改用GROUP BY d.id HAVING COUNT(DISTINCT dt.tag_id) = 3 -
IN子查询一旦嵌套过深（如三层），可读性骤降，且MySQL可能拒绝执行（Subquery returns more than 1 row错误常因内部优化器误判） - 某些场景下，
JOIN能利用物化CTE或临时表缓存中间结果，而反复执行的子查询无法复用
MySQL低版本必须用CONCAT模拟多列匹配（仅限字符串安全场景）
MySQL 5.7及之前不支持多列IN，又无法改用EXISTS时，有人用CONCAT(a, '|', b) IN (SELECT CONCAT(x, '|', y) FROM ...)硬凑。这方法危险：一旦字段含分隔符|或NULL，结果必然错乱。
- 若字段确定为非空数字，可用
CAST(a AS CHAR) + ':' + CAST(b AS CHAR)（SQL Server）或TO_CHAR(a) || ':' || TO_CHAR(b)（PostgreSQL） - 但字符串拼接无法利用索引，全表扫描不可避免；且类型隐式转换可能引发意外截断（如
DECIMAL(5,2)转字符时丢失精度） - 真正稳妥的做法是升级MySQL到8.0+，或重构逻辑为带主键的临时表+多字段JOIN
