1. PG库字段查询基础：理解NOT运算符的本质
PostgreSQL中查询字段不等于特定值的操作，看似简单却暗藏玄机。许多开发者会直接使用!=或<>运算符，但实际场景中还需要考虑NULL值处理、索引利用和性能优化等问题。以查询users表中status字段不等于'active'的记录为例，基础写法是：
SELECT * FROM users WHERE status <> 'active';但这样的查询会遗漏status IS NULL的记录，因为NULL与任何值的比较结果都是未知(UNKNOWN)，不会被WHERE条件选中。这是三值逻辑(TRUE/FALSE/UNKNOWN)的特性使然。
关键注意：在PG中，
!=和<>完全等效，但<>更符合SQL标准。实际执行计划中两者无性能差异。
2. 完整的不等于查询方案设计
2.1 包含NULL值的正确写法
要确保查询结果包含所有非目标值记录（包括NULL），必须显式添加NULL检查：
SELECT * FROM users WHERE status <> 'active' OR status IS NULL;这种写法在业务逻辑上更严谨，特别是当字段允许NULL时。我曾在一个用户管理系统项目中，就因为没有处理NULL值导致统计报表数据缺失30%。
2.2 索引利用优化
如果status字段有索引，上述查询可能无法有效利用。更好的写法是：
SELECT * FROM users WHERE status NOT IN ('active') OR status IS NULL;在PG 12+版本中，这种写法能更好地利用倒排索引。可以通过EXPLAIN命令验证执行计划：
EXPLAIN ANALYZE SELECT * FROM users WHERE status NOT IN ('active');3. 高级场景下的不等于查询
3.1 多字段联合不等于查询
当需要同时满足多个字段不等于条件时，要注意逻辑运算符的优先级：
SELECT * FROM products WHERE category <> 'electronics' AND (price <> 100 OR price IS NULL);括号的使用至关重要，否则可能得到意外的结果集。曾有个电商项目就因缺少括号导致促销商品查询出错。
3.2 JSON字段中的不等于查询
对于JSONB类型字段，需要使用特殊的运算符：
SELECT * FROM orders WHERE attributes->>'payment_status' <> 'paid';这种查询通常无法使用普通索引，建议对JSON字段创建GIN索引：
CREATE INDEX idx_orders_attributes ON orders USING GIN(attributes);4. 性能优化实战技巧
4.1 避免全表扫描的策略
当不等于查询的条件值占比很高时，PG可能选择全表扫描而非索引扫描。这时可以尝试：
SELECT * FROM large_table WHERE id NOT IN ( SELECT id FROM large_table WHERE status = 'inactive' ) LIMIT 1000;4.2 分区表的不等于查询
对于分区表，不等于查询要特别注意分区键的选择：
-- 按created_at分区的情况下 SELECT * FROM logs WHERE log_level <> 'DEBUG' AND created_at BETWEEN '2023-01-01' AND '2023-01-31';这样能有效减少需要扫描的分区数量。在一个日志分析系统中，这种优化将查询时间从15秒降到了200毫秒。
5. 常见问题排查指南
5.1 字符编码导致的查询异常
当字段使用特殊编码时，不等于查询可能出现意外匹配：
-- 如果数据库编码为UTF-8，而客户端是LATIN1 SELECT * FROM products WHERE name <> 'café' COLLATE "en_US.utf8";5.2 隐式类型转换问题
类型不匹配会导致索引失效：
-- 假设status是整数类型 SELECT * FROM orders WHERE status <> '1'; -- 错误的字符串写法正确的写法应该是：
SELECT * FROM orders WHERE status <> 1; -- 使用正确的类型6. 替代方案与最佳实践
6.1 使用EXISTS替代NOT IN
对于子查询场景，EXISTS通常性能更好：
SELECT * FROM customers c WHERE NOT EXISTS ( SELECT 1 FROM blacklist b WHERE b.customer_id = c.id );6.2 物化视图优化频繁查询
对于频繁执行的不等于查询，可以考虑创建物化视图：
CREATE MATERIALIZED VIEW active_users AS SELECT * FROM users WHERE status <> 'inactive' OR status IS NULL; REFRESH MATERIALIZED VIEW active_users; -- 定期刷新在实际项目中，这种方案将用户列表查询响应时间从1200ms降到了80ms。
