在PostgreSQL中创建新表是数据库建模的第一步，但建表语句并不只是简单地写下几个列名和类型。列类型的选择会影响存储空间和查询性能，约束设计直接影响数据完整性，而表级参数如填充因子和日志模式则关系到写入吞吐与故障恢复。如果一开始没有把这些细节理清楚，后期往往需要通过重复的ALTER TABLE来补救，甚至需要停机重建。本文围绕CREATE TABLE操作，从语法、约束、常见错误和性能优化几个方面展开，并结合实际SQL示例说明如何少走弯路。
核心语法与常用选项
PostgreSQL创建表的基本命令是CREATE TABLE。标准语法可以拆成表名、列定义、约束定义和表级选项四部分。最简单的建表语句只需要表名和至少一列：
CREATE TABLE users (
id INT PRIMARY KEY,
username VARCHAR(50) NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
上面这个例子中，id列被定义为主键，username列不允许为空，created_at列默认写入当前事务时间。now()是PostgreSQL内置函数，它在语句执行时返回带时区的时间戳。
实际建表时更推荐加上IF NOT EXISTS，避免表已经存在时报错中断脚本。例如：CREATE TABLE IF NOT EXISTS users (...)。不过这个选项只判断表名是否存在，不会判断结构是否一致，所以不能替代完整的迁移管理。对于临时使用的表，可以指定TEMPORARY或TEMP，这类表只在当前会话可见，连接断开后自动删除。若希望表不写WAL日志以提高批量写入速度，可以使用UNLOGGED，但代价是崩溃后数据可能丢失。
列定义中还可以设置COLLATE、COMPRESSION等选项，但这些通常用于文本排序和TOAST存储优化，基础建表阶段可以先不深入。
数据类型与约束设计
PostgreSQL提供了丰富的数据类型，常见的有INTEGER、BIGINT、NUMERIC、VARCHAR、TEXT、DATE、TIMESTAMPTZ、JSONB等。开发中常见的误区是随便使用VARCHAR(255)或NUMERIC，而忽略了更精确的类型选择。VARCHAR(n)带长度限制会带来额外的长度检查，如果长度不确定，直接使用TEXT通常性能上并不会有明显损失。对于整数主键，若数据量可能超过21亿，应使用BIGINT；对于需要精确小数计算的金额字段，应使用NUMERIC(10,2)而不是DOUBLE PRECISION。
约束方面，PRIMARY KEY会隐式创建唯一索引并拒绝NULL值，一张表只能有一个主键。如果需要多个唯一性限制，使用UNIQUE约束。FOREIGN KEY用于维护引用完整性，但在高并发写入场景下会增加锁开销，需要根据业务权衡。检查约束CHECK可以限制取值范围，例如：
CREATE TABLE products (
id BIGSERIAL PRIMARY KEY,
name TEXT NOT NULL,
price NUMERIC(10,2) NOT NULL CHECK (price > 0),
status VARCHAR(20) DEFAULT 'active' CHECK (status IN ('active','inactive'))
);
这里price > 0被写成了CHECK (price > 0)，价格必须为正数。status列的检查约束限定只能取两个值。注意SQL中>在HTML环境下需要转义为>，上面的代码块已经做了转义处理。约束命名建议显式指定，例如CONSTRAINT positive_price CHECK (price > 0)，这样后续删除或修改约束时不需要查询系统表。
自增列方面，PostgreSQL传统上使用SERIAL或BIGSERIAL，它们本质上是创建一个序列并设置默认值。从PostgreSQL 10开始，推荐使用标准SQL的GENERATED AS IDENTITY，它把序列和列的依赖关系管理得更清晰，防止误删序列：
CREATE TABLE orders (
order_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id BIGINT NOT NULL,
total NUMERIC(12,2) NOT NULL
);
性能与维护层面的建表细节
建表时还需要考虑存储参数和表空间。FILLFACTOR用来控制数据页的填充率，默认是100，意思是完全填满。对于经常发生UPDATE导致行变长的表，可以设置FILLFACTOR=80，预留空间减少页分裂。例如：CREATE TABLE logs (...) WITH (fillfactor = 80);但要注意，降低填充因子会增加磁盘占用和扫描成本，只适合更新频繁的场景。
表空间允许把表或索引放到不同的物理磁盘上，适合冷热数据分离。建表时可以指定TABLESPACE，例如CREATE TABLE archive (...) TABLESPACE slow_disk;。如果数据量非常大，建议在建表时就考虑分区表，PostgreSQL支持声明式分区：
CREATE TABLE events (
id BIGINT GENERATED ALWAYS AS IDENTITY,
occurred_at TIMESTAMPTZ NOT NULL,
payload JSONB
) PARTITION BY RANGE (occurred_at);
CREATE TABLE events_2024 PARTITION OF events
FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
分区表能显著提升大范围时间查询的裁剪效率，但会增加维护复杂度。对于不需要长期保存的中间结果，使用TEMPORARY TABLE更合适；对于批量导入后不再更新的只读表，可以考虑UNLOGGED，但必须接受崩溃丢失的风险。另一个容易忽略的点是COMMENT ON，为表和列添加注释能帮助后续维护者理解字段含义，建议在正式建表脚本中养成习惯。
常见报错与排查路径
建表操作最常见的错误是relation already exists，通常是因为重复执行了包含相同表名的脚本。解决办法是加上IF NOT EXISTS，或者在执行前先DROP TABLE IF EXISTS。第二个高频问题是权限不足：普通用户需要在public模式上有CREATE权限，否则会出现permission denied for schema public。PostgreSQL 15之后public模式的默认创建权限被收紧，需要管理员执行GRANT CREATE ON SCHEMA public TO app_user;。
类型不匹配也是常见坑，例如把字符串写到整数列会报invalid input syntax for type integer。此时应检查插入数据的类型，或者在列定义时使用CASE转换，但更好的做法是在应用层做好类型校验。约束冲突如duplicate key value violates unique constraint说明存在并发写入或重复数据，需要结合业务确定是否要删除唯一约束还是增加冲突处理逻辑。
如果建表本身成功但查询很慢，可以检查是否缺少必要的索引。主键会自动创建索引，但外键列不会自动创建索引，这会导致关联查询时子表被全表扫描。建表后记得为外键列和常用的过滤列创建索引。同时通过\d+ table_name查看表结构、索引和存储参数，确认实际生效的配置是否与预期一致。
PostgreSQL创建表CREATE TABLE修改时间：2026-09-29 02:27:49