ilike 是 postgresql 中 like 的大小写不敏感替代方案，语法一致且性能优于 lower() 配合 like；正则匹配应使用 ~* 而非 ~；需通过函数索引或 citext 类型支持索引加速；lc_collate 影响匹配行为，需谨慎配置。
用 ILIKE 替代 LIKE 是最直接的方式
PostgreSQL 原生支持忽略大小写的模式匹配，ILIKE 就是 LIKE 的大小写不敏感版本。它和 LIKE 语法完全一致，只是比较时自动转为小写（或按当前 LC_COLLATE 规则处理），不需要手动调用函数或改写字段。
常见错误是仍用 LIKE 配合 LOWER()，比如 WHERE LOWER(name) LIKE LOWER('%abc%') —— 这会强制对每行 name 计算函数，无法走索引（除非你建了函数索引），性能差且冗余。
正确写法示例：
SELECT * FROM users WHERE name ILIKE '%admin%';
它等价于在内部做了大小写归一化，但由查询引擎优化执行，比手写 LOWER() 更高效、更简洁。
当需要正则匹配时，用 ~* 而不是 ~
如果模糊逻辑超出 ILIKE 支持的 % 和 _ 模式（比如要匹配“a 或 b 开头 + 数字结尾”），就得上正则。PostgreSQL 中，~ 是大小写敏感正则匹配，~* 才是忽略大小写的版本。
容易踩的坑：有人误以为加 COLLATE "C" 或 ILIKE 能用于正则——不行。ILIKE 只作用于 LIKE-style 模式；正则必须用 ~*。
使用场景举例：
- 查邮箱域名含 “gmail” 但不区分大小写：
email ~* '@gmail\.com$' - 查用户名以 “dev” 或 “DEV” 开头：
username ~* '^dev'
注意：正则中的点号 . 要转义成 \.，否则匹配任意字符；$ 表示行尾，避免匹配到中间子串。
想走索引？得建表达式索引或用 citext 类型
ILIKE 默认无法利用普通 B-tree 索引，因为索引是按原始值排序的，而 ILIKE 的比较逻辑是运行时归一化的。想加速，有两个主流办法：
- 建函数索引：
CREATE INDEX idx_users_name_lower ON users (LOWER(name));，然后配合WHERE LOWER(name) LIKE 'john%'（注意这里仍用LIKE，因为索引是基于LOWER()的） - 把字段类型换成
citext（需先CREATE EXTENSION citext;），它让字段所有比较天然忽略大小写，=、LIKE、索引都自动生效，ILIKE反而变得多余
性能影响明显：没索引时，10 万行表做 ILIKE '%xxx%' 是全表扫描；有 LOWER() 函数索引后，前缀查询（如 LOWER(name) LIKE 'john%'）可走索引，但通配符在开头（'%john'）依然扫全表。
注意区域设置（LC_COLLATE）可能影响结果
ILIKE 和 ~* 的行为依赖数据库集群初始化时设定的 LC_COLLATE。例如在 en_US.UTF-8 下，ß 不等于 ss；但在 de_DE.UTF-8 下可能等价。如果你的应用面向多语言用户，别假设 “忽略大小写 = 英文规则”。
验证当前库的排序规则：
SHOW LC_COLLATE;
临时覆盖（仅当前 session）可用 COLLATE "C"，比如 name ILIKE 'Admin' COLLATE "C"，但这样会失去本地化排序语义，慎用。真正需要稳定行为的场景，建议统一部署环境的 LC_COLLATE，而不是在 SQL 里硬编码。
大小写归一化看着简单，但索引策略、区域设置、正则边界这些细节，漏掉一个就可能让查询慢几倍或结果出错。
