PostgreSQL内置的text类型按照数据库的排序规则进行比较，默认规则下字母A和a是两个不同字符。这种设计在多数场景下是合理的，但遇到邮箱、用户名、域名等需要不区分大小写的字段时，就会产生查询遗漏和唯一约束失效的问题。citext扩展提供的正是大小写不敏感文本类型，它在存储时保留原始大小写，在比较、排序和建立唯一索引时统一折叠成小写。
如何安装citext并创建第一个不区分大小写的表
在PostgreSQL中启用citext之前，需要确认扩展文件是否可用。绝大多数发行版都自带这个扩展，只要以超级用户或具有创建扩展权限的角色执行一条SQL即可。以Linux环境为例，连接目标数据库后运行：
CREATE EXTENSION IF NOT EXISTS citext;
执行成功后，数据库里就多了一种名为citext的数据类型。创建表时可以直接把邮箱、用户名等字段声明成citext，语法与普通文本类型几乎一致。例如创建一个用户表：
CREATE TABLE users (
id serial PRIMARY KEY,
email citext UNIQUE,
display_name citext
);
INSERT INTO users (email, display_name) VALUES
('Tom@Example.com', 'Tom'),
('tom@ipipp.com', 'Tommy');
上面的第二条插入语句会失败，因为email字段上有唯一约束，而citext认为Tom@Example.com与tom@ipipp.com是同一个值。这正是很多业务期望的行为。如果只想允许不同用户使用不同大小写的邮箱，普通text类型更合适。查询时同样不区分大小写，以下两条SQL都能匹配到同一条记录：
SELECT * FROM users WHERE email = 'TOM@EXAMPLE.COM'; SELECT * FROM users WHERE email = 'tom@ipipp.com';
从结果可以看到，citext没有改变存储内容，只是在比较时把两边都转换成小写再判断。这种特性对用户名登录、邮箱查重、域名校验等场景非常实用。
citext与lower函数方案的对比
很多开发者在接触citext之前，会使用lower函数来模拟大小写不敏感。最常见的做法是建立表达式索引：
CREATE TABLE accounts (
id serial PRIMARY KEY,
email text
);
CREATE UNIQUE INDEX accounts_email_lower_idx
ON accounts (lower(email));
SELECT * FROM accounts WHERE lower(email) = lower('Tom@Example.com');
这种方案确实能解决问题，但要求查询条件必须记得调用lower函数，否则索引不会被使用。如果某次查询直接写成email = 'Tom@Example.com'，数据库会执行全表扫描，并且对大写的Tom和小写的tom返回不同结果。citext则把大小写折叠封装在类型内部，无论查询条件是否显式调用lower函数，都能保持行为一致。例如同样写入Tom@Example.com和tom@ipipp.com，使用citext唯一约束会直接拒绝重复值，而表达式索引也能拒绝，但应用层必须记得查询时加lower，写入时也可能绕过唯一约束，除非再增加触发器。
从排序角度看，citext与lower函数在简单ASCII字符上行为接近，但citext使用与数据库排序规则相关的折叠逻辑，lower函数只做字符转换。对于locale设置为C的环境，citext折叠规则相对简单，对于其他语言环境可能涉及特殊字符映射。因此不能把两者完全等价看待。
另一个差异是存储。citext内部基于text存储，不会额外保存转换结果，因此空间占用与text基本相同。lower函数方案需要额外的表达式索引存储，索引体积会增大。从维护成本看，citext是类型级别的方案，更直观，而表达式索引需要开发人员时刻记得查询条件与索引表达式一致。
citext的索引策略与性能注意事项
在citext字段上建立索引并不复杂，因为citext类型有自己的比较函数，可以直接创建普通B-tree索引。例如：
CREATE INDEX users_email_idx ON users (email);
这个索引在查询email = 'TOM@EXAMPLE.COM'时同样会生效，因为类型相等操作符会调用大小写不敏感比较。对于唯一约束，PostgreSQL会自动创建唯一索引，因此在citext列上声明UNIQUE就足够了，无需额外表达式。但如果业务上还要求对citext字段做前缀匹配，比如LIKE 'tom%'，需要注意citext的LIKE操作符是否支持大小写不敏感。在PostgreSQL中，citext类型重载了LIKE操作符，因此WHERE email LIKE 'TOM%'也能匹配tom@ipipp.com。但是这种LIKE查询利用B-tree索引的能力有限，只有使用text_pattern_ops或对应的citext_pattern_ops操作符类才能优化前缀查询。可以创建：
CREATE INDEX users_email_pattern_idx ON users (email citext_pattern_ops);
这样查询email LIKE 'Tom%'时能够使用索引。需要提醒的是，citext_pattern_ops只适用于LIKE和正则匹配，普通等值查询用默认的B-tree索引即可。混用多个索引会增加写入开销，应根据实际查询模式决定是否创建。
性能方面，citext的比较比普通text略慢，因为每次比较都需要对两个值做小写折叠。不过这种开销在绝大多数业务中可以忽略，除非表规模极大且经常做全表排序或哈希连接。如果确定只需要等值和唯一约束，使用citext的额外开销通常小于使用lower函数加表达式索引的维护复杂度。对于写多读少的场景，可以接受；对于超高并发且大小写不敏感需求有限的情况，也可以考虑在应用层统一小写存储。
citext的局限性与替代方案
citext并不是万能的大小写解决方案。它依赖于数据库的区域设置和底层字符分类，对于某些Unicode字符的大小写折叠可能与直觉不符。例如全角英文字母、带重音符号的字符、德语ß等，citext的行为取决于PostgreSQL使用的ICU或libc版本。如果业务需要严格遵循Unicode标准的大小写折叠，citext可能无法完全满足，需要在应用层或使用函数进行规范化。
citext还会把大小写不敏感应用到排序和比较的所有场景，包括GROUP BY、DISTINCT、连接条件等。这通常符合预期，但有时可能过于激进。例如存储用户的显示名称时，如果希望保留大小写不同的两个名字，使用citext就会阻止它们同时存在。此时应该使用普通text，并在查询时按需使用lower或ILIKE。此外，citext类型在与其他类型连接或比较时，可能需要显式转换，例如与varchar字段比较时，citext会利用自己的比较规则，但类型间转换可能隐藏性能问题。
如果业务需要替换已有text字段为citext，可以使用ALTER TABLE修改列类型：
ALTER TABLE users ALTER COLUMN email TYPE citext USING email::citext;
修改前需要确认没有依赖该列类型的视图或函数，并备份数据。修改完成后，原有的唯一约束和索引可能仍然有效，但建议重建相关索引以获得正确的比较行为。如果表数据量较大，这个操作会锁表并重写数据，建议在维护窗口执行。
总体来看，citext适合那些天然需要大小写不敏感比较的字段，如邮箱、用户名、域名、路径片段等。对于需要保留大小写差异或复杂语言规范化需求的场景，应结合应用层和数据库函数自行设计。
citext大小写不敏感PostgreSQL修改时间：2026-09-23 10:15:49