企业官网建设流程全解析

在 PostgreSQL 数据库开发中，字段数据类型选型直接决定数据存储精度、查询性能、存储空间以及业务容错性。很多线上Bug、数据错乱、性能瓶颈，根源都是初期类型选型不规范、时区认知缺失、精度配置混乱。

本文聚焦工作中99%业务场景会用到的核心类型：int/bigint/numeric、text/varchar、timestamp/timestamptz，深度拆解类型特性、存储规则、时区大坑、精度取舍，最后给出可直接落地的字段选型最佳实践，新手可直接照搬，老手可查漏补缺。

本文适配 PostgreSQL 12+ 全版本，所有规则均贴合生产环境实战需求。

一、数值类型：int / bigint / numeric 核心详解

数值类型是业务最基础的类型，用于存储整数、小数、金额、计数等数据，三者的存储特性、性能、精度差异极大，严禁混用。

1.1 整数类型：int（integer）

存储规格：4 字节

取值范围：-2147483648 ~ 2147483647（约 ±21 亿）

核心特点：性能最优、存储空间小、索引效率最高，是普通整数场景的首选类型。

适用场景：普通业务自增ID、状态码、数量、排序值、普通计数器等。

避坑点：预估数据量超 21 亿的场景绝对不能用，会直接触发整数溢出报错，导致数据写入失败。

1.2 大整数类型：bigint

存储规格：8 字节

取值范围：-9223372036854775808 ~ 9223372036854775807（超大范围，几乎不会溢出）

核心特点：存储空间比 int 大一倍，性能略低于 int，但完全杜绝溢出问题，是生产主键的标配。

适用场景：业务主键ID、雪花算法ID、超大计数器、日志流水号、分表主键等。

选型建议：互联网项目所有主键一律用 bigint，无需纠结空间，避免后期数据量增长导致的溢出重构问题。

1.3 高精度数值：numeric

核心定位：PostgreSQL 唯一的精准十进制数值类型，无浮点精度丢失问题。

存储规格：可变长度，根据精度动态占用空间

语法格式：numeric(总位数, 小数位数)，例如 numeric(10,2) 代表总共10位数字，其中小数2位，整数8位。

核心特点：精度绝对准确，无舍入误差；缺点是运算、索引性能远低于 int/bigint，存储开销更大。

适用场景：金额、汇率、手续费、税率、精密统计数据等绝对不能丢失精度的场景。

精度选择最佳实践：

• 通用金额场景：统一使用numeric(16,2)，可满足千万级金额存储

• 高精度金融场景：使用 numeric(20,4)，适配大额、小额精密计算

• 禁止不指定精度直接使用 numeric，会导致存储无限制、性能极差、无法约束数据格式

1.4 数值类型性能优先级

int > bigint > numeric

能使用整数的场景绝不使用 numeric，仅精准计算场景强制使用 numeric，杜绝 float/double 浮点类型（存在天然精度丢失）。

二、字符串类型：varchar / text 选型详解

很多开发者误以为 varchar 性能优于 text，这是典型误区！PostgreSQL 中两种类型底层存储机制几乎一致，性能无明显差异，选型核心看是否需要长度约束。

2.1 varchar（字符可变长度）

语法：varchar(n)，n 为最大字符长度

核心特性：强制长度校验，写入超出长度直接报错，可规范数据格式；支持常规索引、模糊查询。

适用场景：手机号、账号、昵称、身份证号、固定规格编码、短文本字段。

最佳实践：固定长度、有规范约束的短文本，优先用 varchar(n)，利用数据库原生约束保证数据合法性。

2.2 text（无限长文本）

核心特性：无长度限制，无需指定参数，支持超长文本存储；PostgreSQL 对 text 做了深度优化，查询、写入性能不输 varchar。

误区纠正：text 不是“大文本专属”，日常非固定长度的字符串用 text 更灵活，无需预估长度，避免后期字段扩容改表。

适用场景：用户简介、备注、详情描述、文章内容、日志信息、不定长文本。

2.3 字符串选型终极规则

• 有明确长度规范、需要强制校验：varchar(n)

• 无固定长度、内容长短不一：text

• 禁止使用 char(n) 固定长度类型，会自动补空格，造成存储浪费和查询异常

• 不要过度定义 varchar(255)，按需设置长度，减少无效约束

三、时间类型：timestamp / timestamptz（时区大坑重点）

时间类型是 PostgreSQL 最容易踩坑的模块，90%的时间错乱、时区偏移、数据同步问题，都是因为选错 timestamp 和 timestamptz。

3.1 timestamp（不带时区时间）

全称：timestamp without time zone

核心特性：仅存储“时间字面量”，不记录时区信息。数据库不会做任何时区转换，存入什么时间就返回什么时间。

致命问题：

当数据库服务时区、客户端时区、服务器时区不一致时，会出现严重时间错乱！跨环境部署、服务器迁移、时区切换时，数据完全不可用。

适用场景：仅单机本地测试、无跨环境部署、纯静态时间展示场景（生产环境不推荐使用）。

3.2 timestamptz（带时区时间）

全称：timestamp with time zone

核心特性：存储时自动将时间转为 UTC 时间存储，查询时根据当前客户端/数据库时区自动转换为对应本地时间，自带时区适配能力。

存储开销：和 timestamp 完全一致，都是8字节，无性能、存储空间损耗。

生产唯一推荐：所有业务时间字段（创建时间、更新时间、操作时间、过期时间）一律使用 timestamptz。

3.3 全网高频时区大坑详解

大坑1：本地时间直接存入 timestamp，跨环境时差错乱

示例：东八区 2026-08-31 12:00:00 存入 timestamp，部署到UTC时区服务器后，查询依然显示12:00:00，实际真实UTC时间为04:00:00，业务时间完全失真。

大坑2：新旧数据时区不统一，统计对账异常

部分字段用 timestamp、部分用 timestamptz，数据统计、时间范围查询、订单对账会出现隐形偏差，极难排查。

大坑3：数据库时区修改，历史数据全部失效

timestamp 数据依赖写入时的时区，后期修改数据库时区，历史所有时间数据全部偏移，无法自动修复。

3.4 时间类型精度选择

• 默认精度：timestamp/timestamptz 默认支持微秒级精度，满足绝大多数业务

• 普通业务场景：无需手动指定精度，直接使用 timestamptz 即可

• 高精度日志、秒杀、时序场景：保留默认微秒精度，无需额外配置

• 无需使用 date/time 单独类型，业务时间字段统一用 timestamptz，兼容日期+时间查询

四、PostgreSQL 字段类型选型终极最佳实践

结合性能、存储、容错性、业务扩展性，整理可直接落地的生产选型规范，团队开发可直接作为编码规范执行。

4.1 数值类型选型规范

• 普通计数、状态、小范围数值：int

• 主键ID、雪花ID、大数据量计数器：bigint（生产首选）

• 金额、金融、精密计算数据：numeric(16,2)通用，高精度用 numeric(20,4)

• 严禁使用 float/double 存储精准业务数据

4.2 字符串类型选型规范

• 手机号、身份证、账号、固定编码：varchar(规范长度)

• 备注、简介、详情、不定长文本：text

• 禁止使用 char(n)，杜绝无意义的 varchar(255) 滥用

4.3 时间类型选型规范（重中之重）

• 生产环境一律禁用 timestamp

• 所有业务时间字段（create_time、update_time、expire_time等）统一使用timestamptz

• 全局统一时区为 UTC+8，客户端、数据库、服务端时区保持一致

4.4 通用避坑总结

1. 选型优先兼顾扩展性，前期省空间，后期重构成本极高

2. 精准数据拒绝浮点，时间数据拒绝无时区类型

3. 字符串按需约束长度，不盲目使用超长字段

4. 遵循“够用且不溢出、精准且高性能”的核心原则

五、总结

PostgreSQL 数据类型选型看似简单，实则暗藏大量生产坑点。int/bigint 把控数值溢出风险，numeric 保障金融精度，varchar/text 适配不同文本场景，timestamptz 彻底解决时区错乱问题。

规范的类型选型，是数据库性能优化、数据准确性、系统稳定性的基础。本文的选型规范可直接作为团队开发标准，从源头规避90%的数据异常问题。

后续预告：下一篇将讲解 PostgreSQL 索引选型、字段默认值、非空约束、枚举类型实战规范，持续更新 PG 全套生产最佳实践。