PostgreSQL查询数组需注意三点：下标从1开始、空数组与NULL值处理；推荐用ANY或@>判断元素存在，UNNEST需配合LATERAL使用；ARRAY_LENGTH可区分NULL与空数组。
SELECT 语句本身不区分数组字段和普通字段，但查询数组时必须注意下标从 1 开始、空数组行为、NULL 值处理这三点，否则极易查不到数据或报错。
用 WHERE 查数组中某个位置的值
PostgreSQL 数组下标从 1 开始，不是 0。写成 tags[0] 或 tags[-1]（倒序）会返回 NULL，不是错误，但逻辑就断了。
常见错误现象：SELECT * FROM array_demo WHERE tags[1] = 'electronics' 能命中，但 tags[2] 查不到 —— 因为有些行 tags 只有 1 个元素，tags[2] 是 NULL，而 NULL = 'mobile' 永远为 FALSE。
- 安全写法：先用
ARRAY_LENGTH(tags, 1) >= 2确保长度够，再查tags[2] - 更常用的是避免依赖位置，改用
'mobile' = ANY(tags)或tags @> ARRAY['mobile'] - 注意：如果
tags字段本身是 NULL，tags[1]也返回 NULL，不会报错，但 WHERE 条件失效
用 ANY 和 @> 判断数组是否含某元素
ANY 是最直观的成员判断方式，语法轻量；@>（包含操作符）语义更强，支持子数组匹配，且能走 GIN 索引。
使用场景：
- 单值匹配：
WHERE 'SQL' = ANY(skills)—— 简单直接，适合小表或无索引场景 - 多值匹配：
WHERE skills @> ARRAY['Python', 'Docker']—— 要求同时包含两个技能 - 索引依赖：
@>在skills上建 GIN 索引后性能明显优于ANY；ANY即使有索引也常退化为顺序扫描 - 注意：
skills @> '{}'::TEXT[]对空数组返回 TRUE，但对 NULL 字段返回 NULL（即不匹配）
用 UNNEST 把数组展开成多行查
UNNEST 不是过滤手段，而是“行转列”工具。它把一个数组字段炸开成多行，让每个元素单独参与 JOIN 或 GROUP BY。
典型误用：SELECT * FROM array_demo WHERE UNNEST(tags) = 'electronics' —— 语法错误，UNNEST 不能直接放在 WHERE 里。
- 正确写法：用
LATERAL或子查询包裹，例如SELECT id, tag FROM array_demo, LATERAL UNNEST(tags) AS tag WHERE tag = 'electronics' - 性能影响：
UNNEST会放大结果集行数，若原表 100 行、每行tags平均 5 个元素，结果就是约 500 行 —— 注意LIMIT放在最外层才有效 - NULL 安全：如果
tags是 NULL，UNNEST(tags)不产生任何行（即该记录被“丢弃”），需加LEFT JOIN LATERAL ... ON TRUE保留
查数组长度和维度信息要小心 NULL 和空数组
ARRAY_LENGTH 和 ARRAY_DIMS 对 NULL 输入一律返回 NULL，对空数组（如 '{}'::TEXT[]）返回 0 或空字符串，不是报错，但容易漏判。
-
ARRAY_LENGTH(tags, 1)返回 NULL → 字段为 NULL；返回 0 → 字段非 NULL 但为空数组；返回正整数 → 正常 - 检查是否为空数组应写成：
ARRAY_LENGTH(tags, 1) = 0 OR tags IS NULL，不能只写tags IS NULL - 二维数组要明确维度：
ARRAY_LENGTH(related_products, 1)是行数，ARRAY_LENGTH(related_products, 2)是列数；若某行不等长（如ARRAY[[1,2], [3]]），第二维长度取最大列数，未定义位置视为 NULL
数组字段看着像普通字段，但它的 NULL、空、越界、多维结构都会静默影响查询结果。真正麻烦的不是语法记不住，而是这些边界情况在测试数据里不显眼，上线后才突然暴露。
