IN子查询必须返回单列，否则报错“Operand should contain 1 column(s)”；多字段匹配应改用行构造器（如(a,b) IN (SELECT a,b...)）或EXISTS。
IN 子查询返回多列会报错：Operand should contain 1 column(s)
直接在 IN 后面跟一个返回多列的子查询（比如 SELECT id, name FROM users）一定会触发 MySQL 错误：Operand should contain 1 column(s)。因为 IN 只接受单列结果集，它本质上是做「某字段值是否在该列值集合中」的判断。
常见错误写法：
SELECT * FROM orders WHERE (user_id, status) IN (SELECT id, status FROM users);
这种写法看似想匹配“用户ID和状态”的组合，但 MySQL 不支持多列 IN（除非用行构造器，见下一条）。
用行构造器（row constructor）实现多列匹配
MySQL 和 PostgreSQL 支持用括号包裹多个字段，形成行值（row value），再与子查询的多列结果配对。这是真正能表达「多条件联合存在」的合法方式。
-
IN左侧必须是带括号的字段组合，列数、顺序、类型要和子查询严格一致 - 子查询必须只返回对应数量的列，且不能有
ORDER BY或LIMIT（除非用派生表包装） - NULL 值参与比较时整行结果为 UNKNOWN，不会被匹配到（符合三值逻辑）
正确示例：
SELECT * FROM orders WHERE (user_id, status) IN (SELECT id, 'active' FROM users WHERE is_vip = 1);
注意：SQLite 不支持该语法；SQL Server 完全不支持行构造器用于 IN；Oracle 需用 IN (SELECT ...) + 多列等值连接替代。
替代方案：用 EXISTS 替代 IN 处理复杂多条件
当子查询逻辑变复杂（比如要关联多表、加聚合、或需要处理 NULL 安全性），EXISTS 更可靠、语义更清晰，且多数引擎优化更好。
-
EXISTS不受单列限制，子查询可任意结构，只需返回一行即为 true - 避免
IN对 NULL 的意外行为（NULL IN (1,2,NULL)结果是UNKNOWN，不是TRUE） - 若子查询中需引用外部表字段（相关子查询），
EXISTS是唯一自然选择
等价改写示例：
SELECT * FROM orders o
WHERE EXISTS (
SELECT 1 FROM users u
WHERE u.id = o.user_id
AND u.status = o.status
AND u.is_vip = 1
);性能陷阱：IN 子查询可能被重写为 JOIN，但不总如你所愿
MySQL 5.6+ 会对某些 IN 子查询自动半连接（semi-join）优化，但前提是子查询不包含 GROUP BY、DISTINCT、LIMIT 或外部引用（correlation）。一旦触发“物化”（materialization）或“依赖执行”（dependent execution），性能可能断崖式下降。
- 用
EXPLAIN看select_type：若出现DEPENDENT SUBQUERY，说明每行外层都执行一次子查询 - 子查询结果集大时，
IN可能比JOIN慢——因为无法利用外层驱动表的索引下推 - 如果只是取基础数据且条件固定，优先考虑先查出 ID 列表，再用字面量
IN (1,2,3...)（注意上限和 SQL 注入风险）
真正容易被忽略的是：行构造器语法虽然简洁，但很多 ORM（如 Django ORM、MyBatis）默认不生成它，得手写原生 SQL 或用特定方言支持。别假设“写出来就能跑”。
