别再只用 int 和 varchar 了！PostgreSQL 这些“隐藏类型”让你的架构少写一半代码

技术不打烊
24 阅读5分钟

1.png 一睁眼，PostgreSQL（下文简称PG）在Stack Overflow的年度大选中连庄了！

数据不会撒谎。Stack Overflow 最新调研显示，近50%的专业开发者将PG作为首选数据库，直接把昔日王者MySQL甩在身后 。但最扎心的是什么？90%的人还在拿这辆“法拉利”当“拖拉机”开——只用最基础的 int 和 varchar，完全无视了PG真正的黑科技。

连GitLab和Instagram的架构大佬都在感慨：“PG不仅仅是数据库，它是一个带存储功能的开发框架。”（Guys, stop treating it like MySQL!）

今天咱们不聊虚的，直接上干货。盘点4个能让你少写一半代码、早两小时下班的PG隐藏神技。

JSONB —— 在关系库里“白嫖”NoSQL

谁在用，怎么用？ 产品经理又双叒叕要加“用户画像”字段了？放在以前，你得改表结构（DDL）、锁表、甚至停机发布。 但在PG里，老手都懂用 JSONB。

简单来说，就是把这一堆不确定的属性（兴趣、设备信息、临时配置）打包塞进一个字段里。别拿MySQL的JSON说事儿，PG的 JSONB 是存储二进制格式，支持 GIN 索引，查询速度简直离谱。

2025年的硬核评测显示：在特定场景下，PG处理JSONB的读取速度甚至比MongoDB快了1.75倍！[^3]

什么概念？ 以前你要写个复杂的EAV模型（行转列）或者在那拼字符串，现在直接：

-- 查出所有用iPhone且爱看“科技”频道的用户
SELECT * FROM users 
WHERE preferences @> '{"device": "iPhone", "tags": ["tech"]}';

一行SQL搞定，Java代码少写几十行，性能还起飞。

Array 数组类型 —— 消失的“中间表”

多对多关系的“降维打击” 做过“文章-标签”系统的兄弟都懂，传统的教科书式设计是：posts 表、tags 表，中间再来个 post_tags 关联表。 每次查文章带标签，都要 JOIN 两次。数据量一大，DBA就开始在群里@你：“那个谁，慢SQL优化一下。”

老黄确实挺地道 如果标签数量不多（比如每篇不超过50个），直接用 text[] 数组类型把它拍平！

代码量对比（Visualized）：

  • 传统方案：创建3张表，写2个JOIN，应用层还得把结果集重组。
  • PG方案：
-- 表定义：直接存 text[]
CREATE TABLE posts (
    id serial PRIMARY KEY,
    title text,
    tags text[] -- 重点在这！
);

-- 查包含“Python”标签的文章
SELECT * FROM posts WHERE 'Python' = ANY(tags);

这时候肯定有人问：“那性能呢？” 放心，PG支持倒排索引（GIN），查数组快得飞起。把复杂的关联关系变成单表查询，这才是“少写代码”的精髓。

Range 范围类型 —— 解决“预定冲突”的神器

写过会议室预定系统的，出来挨打 判断“新预定时间段”是否和“已有时间段”冲突，是后端开发最头疼的逻辑之一。你得在代码里写： if (new_start < existing_end && new_end > existing_start) ... 如果是高并发场景，还得考虑事务隔离、锁机制……头发都要掉一把。

一行配置，自动拦截 PG直接扔给你一个王炸：Range 类型 + EXCLUDE 约束。

“最好的代码是那些你不需要写的代码，交给数据库引擎去做。”

看看PG怎么做：

CREATE TABLE reservations (
    room_id int,
    during tsrange, -- 时间范围类型
    EXCLUDE USING gist (room_id WITH =, during WITH &&)
);

这一行代码发生了什么？ 它告诉数据库：对于同一个 room_id，任何新插入的 during 时间段，都不能和已有的时间段重叠（&&操作符）。 如果有冲突，数据库直接抛错。原本50行的业务逻辑代码 + 复杂的锁机制，现在变成了0行代码。 这种降维打击，就问你服不服？

Network 类型 —— 垂直领域的专业工具

不但能存IP，还能算距离 很多系统存IP地址还在用 varchar(15)。 问题来了：老板让你查“某个网段下的所有用户”，你是不是得在应用层写正则，或者在SQL里用 like '192.168.%'？如果不小心存了个非IP字符，程序直接崩。

数据不会撒谎 用PG原生的 inet 类型，不仅能校验格式，还能直接算掩码匹配。更重要的是省空间！ 实测数据显示：把 varchar 换成 inet，表大小能减少11%，索引大小更是减少了21% 。

别小看这点空间，在亿级日志表里，这就是几百G的成本差距。对于老板来说，这都是白花花的银子啊！

结语

技术圈有句话：“如果你手里只有锤子，那看什么都是钉子。” 很多时候，我们的代码写得又臭又长，不是因为业务太复杂，而是我们选错了工具。

PostgreSQL 早就不是那个只懂 SELECT * 的老古董了。它用 JSONB 连接了 NoSQL 的灵活，用 Array 简化了关系模型，用 Range 解决了复杂的校验逻辑。

这就是为什么它能连续霸榜 Stack Overflow 的原因——它真的很懂开发者。

最后留个作业： 去翻翻你手头的项目，是不是又在用关联表存只有两三个状态的标签？是不是还在应用层苦哈哈地算时间重叠？ 如果有，明天上班试着重构一下。毕竟，早点下班，去享受生活，才是我们提升技术的最终目的。

avatar
文章
阅读
粉丝