SQL标准不支持直接JOIN数组列，必须先用UNNEST()等函数摊平为行集；PostgreSQL用LATERAL JOIN+UNNEST展开，MySQL等需改用关联表设计，否则性能差且语义易错。
SQL 标准不支持直接 JOIN 数组列——你得先把它“摊平”。 常见错误是试图在 ON 子句里直接写 users.tags = posts.categories，结果要么报错，要么逻辑全错。根本原因是数组不是标量，无法用等值比较参与 JOIN 条件。
PostgreSQL 中用 UNNEST() 展开数组再 JOIN
PostgreSQL 支持数组类型，但 JOIN 时必须把数组转成行集。核心是把数组列作为子查询或 LATERAL JOIN 的输入，用 UNNEST() 拆开：
SELECT u.name, p.title FROM users u CROSS JOIN LATERAL UNNEST(u.tags) AS t(tag) JOIN posts p ON p.category = t.tag;
注意点：
-
CROSS JOIN LATERAL确保每行users都独立展开自己的tags数组 - 如果数组为空或为
NULL，UNNEST()默认不产出行；需要保留原用户行时，改用LEFT JOIN LATERAL - 别在
WHERE里对UNNEST结果过滤后再 JOIN——容易漏掉匹配，应放在ON或外层WHERE
MySQL / SQL Server / SQLite：没有原生数组，得先规范化存储
这些系统没数组类型，所谓“多值列”通常是逗号分隔字符串（如 "tech,sql,backend"），硬 JOIN 会出大问题：
-
FIND_IN_SET()（MySQL）或STRING_SPLIT()（SQL Server 2016+）能拆，但性能差、无法走索引 - 更糟的是
LIKE '%sql%'类模糊匹配——会误中"typescript" - 真正靠谱的做法是拒绝这种设计：把多值属性单独建关联表，比如
user_tags(user_id, tag)
一旦重构为关联表，JOIN 就回归标准写法：JOIN user_tags ut ON ut.user_id = u.id，清晰、可索引、可维护。
JOIN 多值列时最容易被忽略的语义陷阱
即使技术上能 JOIN 成功，业务含义常被想当然：
- 你想要“用户至少有一个标签匹配文章分类”？还是“用户所有标签都必须匹配”？前者是
EXISTS或单次 JOIN，后者得用聚合 + 计数比对 - 数组顺序在大多数场景无意义，但若用
ARRAY_POSITION()（PG）做排序依据，就引入了隐式依赖 - JOIN 后行数可能爆炸：一个用户有 5 个标签、匹配 3 篇文章 → 产生 15 行；没意识到这点，
COUNT(*)和聚合就全歪了
真正麻烦的从来不是怎么写那条 UNNEST()，而是想清楚“这个 JOIN 到底想表达什么关系”，以及“下游应用是否准备好处理爆炸式行数”。数组列进 JOIN，本质是在用非关系模型硬套关系代数——先确认这真是唯一解，再动手摊平。
