SQL中元组(tuple)与数组(array)的区别及语法规则说明
正式定义
- 数组（Array）：SQL标准定义的有序集合类标量值，和整数、字符串一样属于可直接存储在表单元格中的单值类型。同一数组内所有元素必须为相同数据类型，支持固定/可变长度，常见语法为方括号包裹的元素列表
[elem1, elem2, ...]，在PostgreSQL、BigQuery等主流数据库中均支持该语法。 - 元组（Tuple，即行类型Row Type/行构造器Row Constructor）：不属于可存储的标量值范畴，是SQL原生语法结构，用来表示单行多列的结构化值。括号内每个元素对应独立位置的列值，不同位置可存放不同数据类型，本质是对"一行数据"的结构化表达，而非集合类型。
核心差异与常见疑问解答
为什么1 in (1,2)可正常执行，1 in [1,2]会报错？
首先要明确SQL中IN运算符仅支持两类合法右值：
- 逗号分隔的行构造器语法：即
value IN (v1, v2, v3...)形式，这里的括号不是"集合"的标识，就是行构造器的语法符号。当右值行构造器内全为同类型标量、且左值为单个标量时，SQL会自动将该表达式展开为value = v1 OR value = v2 OR value = v3...的等价逻辑，属于纯语法糖，根本不是在做集合成员判断。这就是1 in (1,2)、country in ('ca','fr')能正常运行的核心原因。 - 单列多行结果集：即
value IN (subquery/表函数返回结果)形式，这才是真正的集合成员判断逻辑，要求右值必须能输出多行同类型的匹配值。
而[1,2]是单个数组类型的标量值，既不符合行构造器的语法要求（行构造器必须是括号包裹，不是方括号），也不是多行结果集，拿整数类型的左值和数组类型的单值做匹配，类型完全不兼容，自然会报错。如果要判断元素是否属于数组，需要使用数据库配套的数组操作语法，比如PostgreSQL用1 = ANY(ARRAY[1,2])，BigQuery用1 IN UNNEST([1,2])。
("us", "ca")这类写法是元组还是行类型？
SQL标准里二者没有区别，这类括号包裹逗号分隔值的写法，就是原生的行类型（行值），不存在独立于行类型的"元组集合"概念。你写的("us", "ca")本质是一个包含2个字符串列的单行值，只是刚好出现在IN运算符之后时，触发了前面提到的语法糖展开规则，才会被很多人误以为是和Python元组类似的不可变集合。
测试用例结果解释
你写的三组测试用例的运行结果完全符合上述规则：
-- UNNEST场景 SELECT country FROM unnest(['us', 'ca', 'fr']) as country -- 正常运行 WHERE country in unnest(['ca', 'fr']) -- 正常运行
UNNEST是数组拆分行函数，作用是把单个数组值拆成单列多行的结果集，刚好满足FROM子句需要接收结果集、IN子句需要接收多行匹配值的要求，因此可以正常执行。
-- 括号行值场景 SELECT country FROM ('us', 'ca', 'fr') as country -- 报错 WHERE country in ('ca', 'fr') -- 正常运行
- FROM子句要求接收多行结果集，但
('us', 'ca', 'fr')是单行三列的行值，不是多行集合，无法作为表来源使用，因此报错。 - WHERE子句中的
('ca', 'fr')触发了IN的语法糖规则，自动展开为country = 'ca' OR country = 'fr'，因此正常运行。
-- 数组直接使用场景 SELECT country FROM ['us', 'ca', 'fr'] as country -- 报错 WHERE country in ['ca', 'fr'] -- 报错
两处报错原因一致：方括号包裹的['us', 'ca', 'fr']是单个数组类型的标量值，既不是FROM可识别的多行结果集，也不是IN支持的括号行构造器语法/多行结果集，类型完全不匹配，因此执行失败。
不要直接套用Python的list/tuple逻辑理解SQL：Python中list和tuple都是可迭代的集合类型，仅存在可变性差异，成员判断逻辑完全一致；但SQL中的括号行构造器、方括号数组从底层设计上就不属于同一类事物，一个是语法结构，一个是具体的标量数据类型，行为逻辑自然存在本质区别。不同数据库对行类型、数组的实现细节略有差异，但核心设计逻辑均遵循SQL标准。
内容的提问来源于stack exchange，提问作者David542
