ilike是postgresql特有的不区分大小写的模式匹配操作符，非函数，语法同like但自动忽略ascii字母大小写，支持%和_通配符，可直接用于where和on条件，无需lower()包裹。
ILIKE 本质是 PostgreSQL 的扩展操作符，不是函数
很多人误以为 ILIKE 是个函数，结果写成 ILIKE(column, 'value') 报错。它其实是 PostgreSQL 自带的模式匹配操作符，语法和 LIKE 完全一致，只是忽略大小写。底层用的是 citext 类似逻辑，但不依赖额外扩展，开箱即用。
常见错误现象：ERROR: function ilike(unknown, unknown) does not exist —— 这说明你把它当函数调用了。
- 正确写法：
WHERE name ILIKE 'alice' - 支持通配符：
WHERE email ILIKE '%@gmail.com' - 不能加括号或逗号分隔参数
ILIKE 和 LOWER() + LIKE 的性能差异明显
ILIKE 在有索引时能走索引（需配合 text_pattern_ops 或更推荐的 pg_trgm），而 LOWER(column) LIKE LOWER('...') 几乎一定无法利用普通 B-tree 索引，除非你建了函数索引（如 CREATE INDEX ON users (LOWER(name))）。
- 简单等值场景：优先用
ILIKE 'abc'（注意单引号包裹字面量） - 前缀查询（如
'abc%'）：B-tree 索引 +text_pattern_ops可加速 - 任意位置模糊匹配（如
'%abc%'）：必须启用pg_trgm扩展并建GIN索引，否则全表扫描 - 别写
LOWER(name) ILIKE 'abc'—— 多余且干扰优化器
中文、emoji 和特殊字符在 ILIKE 中的行为
ILIKE 的“不区分大小写”只对 ASCII 字母生效（即 A–Z / a–z）。中文、数字、emoji、标点符号没有大小写概念，所以不受影响；但某些带重音的拉丁字母（如 é、ñ）是否被当作等价，取决于数据库的 LC_COLLATE 设置。
- 默认
en_US.UTF-8下，'ÉTÉ' ILIKE 'été'可能返回 false —— 因为重音字符未归一化 - 需要精确处理变音符号时，应配合
unaccent()函数（需unaccent扩展） - 中文搜索完全没问题：
name ILIKE '%张%'正常工作，无需额外转换 - emoji 不会出错，但也不能“模糊匹配”相似 emoji（比如 ? 和 ?? 被视为完全不同字符串）
替代方案：什么时候不该用 ILIKE
如果查询条件固定、字段内容规范，且你控制写入格式，用普通 = 配合写入时标准化（如统一转小写存入）反而更高效。另外，全文检索需求（如关键词权重、同义词）应直接上 to_tsvector + @@，而非硬套 ILIKE。
- 高频等值查询：存
LOWER(name)并建唯一索引，查时用= 'alice' - 需要高亮/排名/分词：改用
tsquery相关函数 - 跨多列组合模糊搜索：
ILIKE很难优化，考虑物化视图预拼接字段或外部搜索引擎 - 注意：JSON 字段里字符串不能直接
ILIKE，得先用->>提取为 text 再查
ILIKE 在不同 locale 或缺失 trigram 索引时，性能可能差几个数量级。
