电商订单表需要承载用户下单、支付、发货、售后等全链路业务数据，建模时需要先梳理核心业务属性，同时考虑postgresql的特性适配高并发写入场景。电商订单的核心信息包括订单基础信息、商品信息、支付信息、用户信息等，基础建模需要覆盖这些维度的同时避免过度冗余。
电商订单表基础建模设计
基础订单表需要包含订单唯一标识、用户关联、订单状态、金额、时间等核心字段，同时为了提升查询效率，需要合理设置主键与基础索引。以下是基础订单表的创建示例：
-- 创建电商基础订单表
CREATE TABLE ecommerce_order (
order_id BIGSERIAL PRIMARY KEY, -- 订单唯一ID，使用BIGSERIAL适配大量订单场景
user_id BIGINT NOT NULL, -- 下单用户ID
order_sn VARCHAR(64) NOT NULL UNIQUE, -- 订单编号，业务唯一标识
total_amount DECIMAL(10,2) NOT NULL, -- 订单总金额
order_status SMALLINT NOT NULL DEFAULT 0, -- 订单状态：0待支付 1已支付 2已发货 3已完成 4已取消
pay_amount DECIMAL(10,2), -- 实际支付金额
pay_time TIMESTAMP, -- 支付时间
create_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, -- 下单时间
update_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP -- 最后更新时间
);
-- 创建用户ID索引，方便查询用户的订单列表
CREATE INDEX idx_ecommerce_order_user_id ON ecommerce_order(user_id);
-- 创建订单状态+创建时间组合索引，方便按状态筛选近期订单
CREATE INDEX idx_ecommerce_order_status_create_time ON ecommerce_order(order_status, create_time);
订单商品关联表建模
一个订单可能包含多个商品，因此需要单独设计订单商品关联表，避免订单表字段冗余，符合数据库第三范式：
-- 创建订单商品关联表
CREATE TABLE ecommerce_order_item (
item_id BIGSERIAL PRIMARY KEY,
order_id BIGINT NOT NULL, -- 关联订单ID
goods_id BIGINT NOT NULL, -- 商品ID
goods_name VARCHAR(128) NOT NULL, -- 商品名称快照，避免商品信息变更后订单信息不一致
goods_price DECIMAL(10,2) NOT NULL, -- 下单时商品单价
goods_num INT NOT NULL, -- 购买数量
item_total DECIMAL(10,2) NOT NULL, -- 该商品项总金额
create_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
-- 外键关联订单表，保证数据一致性
CONSTRAINT fk_order_item_order_id FOREIGN KEY(order_id) REFERENCES ecommerce_order(order_id)
);
-- 创建订单ID索引，方便查询订单下的所有商品
CREATE INDEX idx_ecommerce_order_item_order_id ON ecommerce_order_item(order_id);
postgresql高写入场景建模技巧
电商大促时段订单写入量可能达到平时的数十倍，基础建模无法满足高写入需求，需要结合postgresql的特性做针对性优化。
分表策略降低单表压力
当订单表数据量超过千万级时，单表写入性能会明显下降，推荐使用postgresql的原生分区表功能，按时间维度对订单表进行分区，比如按月分区：
-- 创建分区主表，基础结构和普通订单表一致，不需要存储数据
CREATE TABLE ecommerce_order_partition (
order_id BIGSERIAL,
user_id BIGINT NOT NULL,
order_sn VARCHAR(64) NOT NULL,
total_amount DECIMAL(10,2) NOT NULL,
order_status SMALLINT NOT NULL DEFAULT 0,
pay_amount DECIMAL(10,2),
pay_time TIMESTAMP,
create_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
update_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY(order_id, create_time) -- 分区键需要包含在主键中
) PARTITION BY RANGE (create_time);
-- 创建2024年1月的分区表
CREATE TABLE ecommerce_order_202401 PARTITION OF ecommerce_order_partition
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
-- 创建2024年2月的分区表
CREATE TABLE ecommerce_order_202402 PARTITION OF ecommerce_order_partition
FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');
分区表的写入会自动路由到对应的分区，单分区数据量可控，写入锁竞争会大幅减少，同时查询时如果带了分区键条件，会只扫描对应分区，提升查询效率。
优化索引减少写入开销
索引会提升查询效率，但每次写入数据时都需要更新所有相关索引，会增加写入开销。高写入场景下需要遵循以下索引优化原则：
- 只保留必要的索引，删除冗余索引，比如不需要按商品ID查询订单的话，就不要给商品ID加索引
- 避免在频繁更新的字段上建索引，比如
update_time字段如果每次更新订单都会修改，就不需要单独建索引 - 可以使用部分索引，比如只给未支付状态的订单建索引，减少索引维护成本：
-- 给未支付状态的订单创建部分索引，只维护符合条件的索引数据 CREATE INDEX idx_ecommerce_order_unpaid ON ecommerce_order(user_id, create_time) WHERE order_status = 0;
批量写入与异步提交优化
高并发写入时，单条插入的性能远低于批量插入，业务层可以攒批写入订单数据，比如每100条订单批量执行一次插入：
-- 批量插入订单示例 INSERT INTO ecommerce_order (user_id, order_sn, total_amount, order_status) VALUES (1001, 'ORD20240101001', 199.00, 0), (1002, 'ORD20240101002', 299.00, 0), (1003, 'ORD20240101003', 399.00, 0);
同时可以开启postgresql的异步提交，牺牲极少量的数据一致性（最多丢失1秒内的数据）来提升写入性能，修改postgresql.conf配置：
-- 开启异步提交，写入时不需要等待WAL日志刷盘 synchronous_commit = off
避免热点行锁竞争
如果订单表有自增主键，高并发写入时可能会出现主键序列的锁竞争，可以使用BIGSERIAL替代SERIAL，或者调整序列的缓存大小，减少序列获取的锁冲突：
-- 创建缓存大小为100的序列，减少序列获取的锁竞争 CREATE SEQUENCE order_id_seq CACHE 100;
另外如果业务中有订单编号生成的逻辑，尽量不要在数据库层面做唯一性校验，可以在业务层生成唯一订单号，减少数据库的unique约束带来的开销。
建模注意事项
建模时还需要注意字段类型的选择，比如金额字段使用DECIMAL而不是FLOAT，避免精度丢失；时间字段使用TIMESTAMP而不是字符串存储，方便后续时间相关的查询与计算。同时订单表不建议存储过多的扩展字段，如果有个性化的订单属性，可以单独设计订单扩展表，通过订单ID关联，避免主表字段过多影响写入性能。
postgresql电商订单表建模高写入优化数据库设计分表策略修改时间：2026-07-03 19:00:35