行构造器子查询要求左右字段数量、顺序及类型严格一致，否则报错或逻辑错误；MySQL 8.0.19+ 支持 (a,b) IN (SELECT x,y...)，不支持 = 形式；PostgreSQL 全面支持；需配合复合索引且注意 NULL 处理。
行构造器子查询的语法结构必须严格匹配字段数量和类型
SQL标准支持用 (col1, col2) 这样的行构造器（row constructor）配合 IN 或比较操作符，一次性匹配多列。但前提是子查询返回的列数、顺序、数据类型必须与左侧完全一致，否则直接报错——比如 PostgreSQL 报 ERROR: 42601: subquery has too many columns，MySQL 可能静默失败或触发隐式转换。
常见错误是子查询只选了单列却用双字段行构造器，或者字段顺序颠倒导致逻辑错配：
-
WHERE (a, b) IN (SELECT x, y FROM t)✅ 正确：两列对两列，顺序一致 -
WHERE (a, b) IN (SELECT x FROM t)❌ 错误：左侧2列，右侧1列 -
WHERE (a, b) IN (SELECT y, x FROM t)❌ 危险：类型不匹配或语义反转（如把 user_id 和 status 调换）
PostgreSQL 和 MySQL 对行构造器的支持差异明显
PostgreSQL 完整支持 SQL 标准行构造器，包括 =、IN、NOT IN、IS NULL 等；MySQL 从 8.0.19 开始才支持 IN 中的行构造器，且不支持 = 形式（会报 ERROR 3097: Row expressions are not supported）。
实操建议：
- 跨数据库迁移时，避免用
(a,b) = (SELECT x,y...)，改用EXISTS+ 关联条件更稳妥 - MySQL 中必须写成
(a,b) IN (SELECT x,y FROM t)，不能省略括号或拆成两个独立条件 - PostgreSQL 允许
(a,b) > (10,'active')这类字典序比较，MySQL 不支持
用 EXISTS 替代 IN 行构造器可规避 NULL 值陷阱
当子查询结果含 NULL 时，(a,b) IN (SELECT x,y...) 整体结果为 UNKNOWN，导致该行被过滤掉——这常被误认为“数据丢失”，实际是三值逻辑生效。例如 SELECT * FROM orders WHERE (status, priority) IN (SELECT s, p FROM config WHERE active IS NULL)，只要子查询任意一列有 NULL，整行就不匹配。
更可靠的做法是显式用 EXISTS：
SELECT * FROM orders o WHERE EXISTS ( SELECT 1 FROM config c WHERE c.s = o.status AND c.p = o.priority AND c.active IS TRUE );
这样能精确控制空值处理逻辑，也更容易加索引（(s,p) 复合索引可被利用）。
性能关键：复合索引必须覆盖行构造器所有字段
行构造器子查询能否走索引，取决于子查询的 SELECT 字段是否被复合索引最左前缀覆盖。例如 (status, priority) IN (SELECT s, p FROM config)，只有当 config 表上有 INDEX idx_config_sp (s, p) 时，才能高效执行；如果只有 INDEX idx_config_s (s)，则仍需全表扫描。
注意点：
- 字段顺序必须一致：索引是
(p, s)，但查询写成(s, p)，多数引擎无法使用该索引 - WHERE 条件中对索引字段的非等值过滤（如
s > 'draft'）会让后续字段失效，此时p不再参与索引查找 - PostgreSQL 的
ROW()函数写法（如ROW(a,b) = ROW(1,'x')）同样依赖相同索引策略
行构造器看着简洁，但字段对齐、空值逻辑、索引覆盖这三点漏掉任一，就容易查不到数据或慢得离谱。
