SQL标准支持多列IN子查询，但要求左右列数、顺序、类型严格一致；MySQL 5.7及更早版本不支持，会报“Operand should contain 1 column(s)”错误；不支持时应改用EXISTS或显式值列表。
多列IN子查询的语法结构必须严格匹配列数和顺序
SQL标准（如PostgreSQL、SQL Server）允许用 (col1, col2) 形式搭配 IN 和子查询，但前提是左右两边的列数、数据类型、顺序完全一致。MySQL 8.0+ 和 Oracle 也支持，但 MySQL 5.7 及更早版本不支持多列 IN 子查询——它会直接报错 ERROR 1241 (21000): Operand should contain 1 column(s)。
常见错误是写成：WHERE (a, b) IN (SELECT a, b FROM t2 WHERE ...) 却忘了子查询里 a 和 b 的顺序是否与外层括号中一致；或者子查询返回了三列，而外层只写了两列。
- 确保子查询 SELECT 列表恰好有 N 列，且与外层
(col1, col2, ...)的数量、顺序、类型兼容 - 避免在子查询中使用
*—— 显式写出列名，防止后期加字段导致隐式错配 - 若数据库不支持（如旧版 MySQL），改用
EXISTS或自连接替代
用EXISTS替代时要注意关联条件不能漏掉NULL安全判断
当多列组合中可能含 NULL，IN 会整体失效（因为 (1, NULL) = (1, NULL) 返回 UNKNOWN，不被 IN 视为匹配），而 EXISTS 更可控。
正确写法示例（过滤订单中「商品ID+仓库ID」同时存在于库存表中的记录）：
SELECT o.*
FROM orders o
WHERE EXISTS (
SELECT 1
FROM inventory i
WHERE i.product_id = o.product_id
AND i.warehouse_id = o.warehouse_id
);-
EXISTS不受NULL值短路影响，逻辑更可靠 - 务必显式写出所有关联字段的等值条件，不要依赖子查询里的
WHERE隐含过滤 - 子查询中避免无意义的
SELECT *，用SELECT 1即可
性能差异：IN子查询易触发全表扫描，需确认执行计划
多列 IN 子查询在某些场景下无法有效利用复合索引，尤其当子查询结果集较大或含复杂过滤时，优化器可能放弃使用索引，转为嵌套循环或哈希连接。
验证方法：在 PostgreSQL 中用 EXPLAIN ANALYZE，在 MySQL 中用 EXPLAIN FORMAT=TREE，重点看是否出现 Materialize 或 Using temporary。
- 若子查询结果固定且较小（如几十行），可考虑用显式值列表代替：
WHERE (a,b) IN ((1,'x'), (2,'y')) - 确保被关联的列上有合适复合索引，例如
CREATE INDEX idx_inv_prod_wh ON inventory(product_id, warehouse_id) - 避免在子查询中使用未索引字段的
ORDER BY或LIMIT，这可能导致优化器误判
不同数据库对空结果集的处理行为不一致
当子查询返回空结果集（0 行），WHERE (a,b) IN (SELECT ...) 整体判定为 FALSE，这是标准行为；但部分旧驱动或 ORM 在参数化查询中拼接空集合时，可能生成语法错误（如 IN ()），需提前拦截。
- 应用层应检查子查询结果是否为空，为空时跳过该条件或改用
WHERE 1=0 - 不要依赖数据库自动处理空集——PostgreSQL 允许
IN (SELECT ...)返回空，但 SQLite 会报错subselect returns 0 columns（如果没写列） - 测试时务必覆盖子查询无数据的边界情况，否则上线后可能查不到任何记录却无报错
多列 IN 嵌套子查询看着简洁，但列对齐、NULL 处理、空集兜底、执行计划这几处最容易出问题，尤其是跨数据库迁移或升级时，旧 SQL 可能突然失效。
