多列in子查询必须用括号包裹列组合，如(customer_id, order_date)in(select customer_id, order_date from t)，否则报错或逻辑错误；mysql 5.7+支持，旧版需用exists或join替代。
多列IN子查询语法必须用括号包裹列组合
SQL标准要求多列IN子查询的左侧必须是带括号的列元组，否则会报错或逻辑错误。比如表 orders 有复合主键 (customer_id, order_date)，你想查匹配的记录，不能写成 WHERE customer_id IN (...) AND order_date IN (...)——这会导致笛卡尔式误匹配。
正确写法是把两列一起括起来：
SELECT * FROM orders WHERE (customer_id, order_date) IN ( SELECT customer_id, order_date FROM recent_customers );
常见错误现象：ERROR: syntax error at or near ","（PostgreSQL）、ORA-00920: invalid relational operator（Oracle），基本都是因为漏了外层括号。
MySQL 5.7+ 和 MariaDB 支持，但低版本不兼容
MySQL 在 5.7 及以后才完整支持多列 IN 子查询；5.6 及更早版本会直接报错 Operand should contain 1 column(s)，即使你写了括号也没用。
替代方案（兼容旧版）：
- 用
EXISTS+ 相关子查询，语义等价且兼容性好 - 拼接字段（如
CONCAT(customer_id, '-', order_date)），但要注意类型隐式转换和分隔符冲突风险 - 改用
JOIN，通常性能更好
子查询返回 NULL 会导致整行不匹配
如果子查询中任意一行的 customer_id 或 order_date 是 NULL，那么该行在 IN 列表中会被视为未知（UNKNOWN），导致外层条件永远不成立——这是 SQL 三值逻辑的典型表现。
排查建议：
- 检查子查询是否过滤了
NULL：WHERE customer_id IS NOT NULL AND order_date IS NOT NULL - 避免在子查询里用
LEFT JOIN引入可能的NULL值 - PostgreSQL 和 SQL Server 中可加
NOT NULL约束保证源头干净
性能差异大：IN 子查询 vs JOIN
多列 IN 子查询在大多数引擎中无法利用索引下推，尤其当子查询结果集较大时，执行计划常退化为嵌套循环或临时表扫描。
实操建议：
- 子查询结果少于几百行，
IN写法简洁可读，影响不大 - 超过千行，优先改用
INNER JOIN，并确保连接列上有联合索引（如INDEX(customer_id, order_date)） - PostgreSQL 中可启用
enable_hashjoin=off测试是否因哈希表构建开销过大而变慢
复合主键场景下，最容易被忽略的是子查询字段顺序必须与外层括号内列顺序严格一致——(order_date, customer_id) 和 (customer_id, order_date) 完全不等价，也不会报错，只会查不到数据。
