设计一个电商平台的数据库表结构（涉及商品、订单、用户等）

来源：这里教程网时间：2026-02-28 20:05:02 作者：

设计一个电商平台的数据库表结构，在我看来，这不仅仅是简单地列出几张表和字段，更是一次对业务逻辑深思熟虑的抽象与建模。核心目标是构建一个既能支撑当前业务需求，又具备良好扩展性的数据基石，确保用户、商品和订单这三大核心支柱能够高效、稳定地运转。

解决方案

一个电商平台的核心数据模型通常围绕用户、商品、订单这三大实体展开，并辅以必要的辅助信息，如分类、购物车、地址、支付等。以下是我认为一套合理且实用的表结构设计：

1. 用户相关 (Users & Authentication)

users
表：存储平台所有注册用户的基础信息。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 用户唯一标识。 username
(VARCHAR(50), UNIQUE): 用户名，可用于登录。 email
(VARCHAR(100), UNIQUE): 邮箱，可用于登录、找回密码、通知。 phone_number
(VARCHAR(20), UNIQUE): 手机号，可用于登录、验证、通知。 password_hash
(VARCHAR(255)): 密码哈希值，务必加密存储。 nickname
(VARCHAR(50)): 用户昵称。 avatar_url
(VARCHAR(255)): 用户头像URL。 registration_date
(DATETIME): 注册时间。 last_login_date
(DATETIME): 最后登录时间。 status
(TINYINT): 用户状态 (e.g., 0: 禁用, 1: 正常, 2: 未激活)。 created_at
(DATETIME): 记录创建时间。 updated_at
(DATETIME): 记录最后更新时间。 user_addresses
表：存储用户的收货地址。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 地址唯一标识。 user_id
(FK, BIGINT UNSIGNED): 关联
users
表。 recipient_name
(VARCHAR(50)): 收货人姓名。 phone_number
(VARCHAR(20)): 收货人手机号。 province
(VARCHAR(50)): 省份。 city
(VARCHAR(50)): 城市。 district
(VARCHAR(50)): 区/县。 detail_address
(VARCHAR(255)): 详细地址。 postcode
(VARCHAR(10)): 邮政编码。 is_default
(BOOLEAN): 是否为默认地址。 created_at
(DATETIME): 创建时间。 updated_at
(DATETIME): 更新时间。

2. 商品相关 (Products & Catalog)

categories
表：商品分类，支持多级分类。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 分类ID。 name
(VARCHAR(50)): 分类名称。 parent_id
(BIGINT UNSIGNED, DEFAULT NULL): 父级分类ID，用于实现树形结构。 level
(TINYINT): 分类层级。 sort_order
(INT): 排序。 is_active
(BOOLEAN): 是否启用。 created_at
(DATETIME): 创建时间。 updated_at
(DATETIME): 更新时间。 brands
表：商品品牌信息。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 品牌ID。 name
(VARCHAR(100), UNIQUE): 品牌名称。 logo_url
(VARCHAR(255)): 品牌Logo URL。 description
(TEXT): 品牌描述。 created_at
(DATETIME): 创建时间。 updated_at
(DATETIME): 更新时间。 products
表：商品基本信息。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 商品ID。 name
(VARCHAR(255)): 商品名称。 description
(TEXT): 商品描述。 category_id
(FK, BIGINT UNSIGNED): 关联
categories
表。 brand_id
(FK, BIGINT UNSIGNED): 关联
brands
表。 main_image_url
(VARCHAR(255)): 商品主图URL。 status
(TINYINT): 商品状态 (e.g., 0: 下架, 1: 上架, 2: 草稿)。 created_at
(DATETIME): 创建时间。 updated_at
(DATETIME): 更新时间。 product_images
表：商品多图。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 图片ID。 product_id
(FK, BIGINT UNSIGNED): 关联
products
表。 image_url
(VARCHAR(255)): 图片URL。 sort_order
(INT): 图片排序。 product_skus
表：商品SKU（库存单位），处理多规格商品。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): SKU ID。 product_id
(FK, BIGINT UNSIGNED): 关联
products
表。 sku_code
(VARCHAR(100), UNIQUE): SKU编码，用于商家内部管理。 attributes_json
(JSON): SKU属性组合，例如
{"颜色": "红色", "尺码": "L"}
。 price
(DECIMAL(10, 2)): SKU价格。 stock
(INT): SKU库存量。 original_price
(DECIMAL(10, 2)): 市场价/原价。 weight
(DECIMAL(10, 2)): SKU重量。 created_at
(DATETIME): 创建时间。 updated_at
(DATETIME): 更新时间。

3. 订单相关 (Orders & Transactions)

orders
表：订单主表。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 订单ID。 user_id
(FK, BIGINT UNSIGNED): 关联
users
表。 order_sn
(VARCHAR(32), UNIQUE): 订单号，通常由业务逻辑生成，具备唯一性。 total_amount
(DECIMAL(10, 2)): 订单总金额（包含运费、优惠前）。 actual_amount
(DECIMAL(10, 2)): 实际支付金额（优惠后）。 shipping_fee
(DECIMAL(10, 2)): 运费。 discount_amount
(DECIMAL(10, 2)): 优惠金额。 payment_method
(VARCHAR(50)): 支付方式 (e.g., 支付宝, 微信支付)。 payment_status
(TINYINT): 支付状态 (e.g., 0: 未支付, 1: 已支付, 2: 部分支付, 3: 退款中, 4: 已退款)。 order_status
(TINYINT): 订单状态 (e.g., 0: 待付款, 1: 待发货, 2: 待收货, 3: 已完成, 4: 已取消, 5: 退款中, 6: 已退款)。 shipping_address_id
(FK, BIGINT UNSIGNED): 关联
user_addresses
表（下单时的快照，也可以直接存储地址详情）。 delivery_sn
(VARCHAR(50)): 物流单号。 delivery_company
(VARCHAR(50)): 物流公司。 created_at
(DATETIME): 订单创建时间。 paid_at
(DATETIME): 支付时间。 shipped_at
(DATETIME): 发货时间。 received_at
(DATETIME): 收货时间。 completed_at
(DATETIME): 订单完成时间。 updated_at
(DATETIME): 订单最后更新时间。 order_items
表：订单商品明细。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 订单项ID。 order_id
(FK, BIGINT UNSIGNED): 关联
orders
表。 product_id
(FK, BIGINT UNSIGNED): 关联
products
表。 sku_id
(FK, BIGINT UNSIGNED): 关联
product_skus
表。 product_name
(VARCHAR(255)): 商品名称快照。 sku_attributes_snapshot
(JSON): SKU属性快照，例如
{"颜色": "红色", "尺码": "L"}
。 price
(DECIMAL(10, 2)): 下单时商品单价。 quantity
(INT): 购买数量。 total_price
(DECIMAL(10, 2)): 该商品项总价 (
price * quantity
)。 carts
表：购物车。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 购物车项ID。 user_id
(FK, BIGINT UNSIGNED): 关联
users
表。 product_id
(FK, BIGINT UNSIGNED): 关联
products
表。 sku_id
(FK, BIGINT UNSIGNED): 关联
product_skus
表。 quantity
(INT): 购买数量。 added_at
(DATETIME): 加入购物车时间。 updated_at
(DATETIME): 更新时间。 payments
表：支付流水记录。 id
(PK, BIGINT UNSIGNED, AUTO_INCREMENT): 支付ID。 order_id
(FK, BIGINT UNSIGNED): 关联
orders
表。 transaction_id
(VARCHAR(64), UNIQUE): 支付平台交易号 (如支付宝交易号)。 payment_method
(VARCHAR(50)): 支付方式。 amount
(DECIMAL(10, 2)): 支付金额。 status
(TINYINT): 支付状态 (e.g., 0: 待支付, 1: 支付成功, 2: 支付失败, 3: 退款)。 paid_at
(DATETIME): 支付成功时间。 created_at
(DATETIME): 支付记录创建时间。 updated_at
(DATETIME): 支付记录更新时间。

如何处理商品的多规格（SKU）问题，并确保库存准确性？

商品多规格（SKU）的管理在电商平台中是极其关键的一环，因为它直接影响到商品的展示、定价、库存以及订单处理。我的经验告诉我，如果这一块设计不当，后续的业务扩展和数据一致性会成为巨大的噩梦。

在我的设计中，

product_skus

表就是解决这个问题的核心。

products

表负责存储商品的基本信息，比如商品名称、描述、主图等，这些信息对于所有规格的商品都是通用的。而

product_skus

表则承载了商品的具体规格组合、对应的价格、独立的库存以及唯一的SKU编码。

具体来说，

product_skus

表中的

product_id

字段通过外键关联到

products

表，表明这个SKU属于哪个商品。

attributes_json

字段是一个非常灵活的设计，它允许我们以JSON格式存储任意数量的规格属性及其值，例如

{"颜色": "红色", "尺码": "L"}

。这种方式避免了为每个可能的属性组合创建大量额外表的复杂性，尤其适用于属性种类不固定或属性值较多的情况。当然，如果属性种类固定且数量少，也可以考虑更规范化的属性-属性值表结构，但这会增加查询和维护的复杂性。

库存准确性是重中之重。每个

product_skus

记录都有一个

stock

字段，它代表了该特定SKU的可用库存量。当用户下单时，库存的扣减必须是原子性操作，以防止超卖。通常，这会在数据库事务中完成：

-- 假设用户购买了SKU ID为101的商品，数量为2
START TRANSACTION;
-- 检查库存是否充足
SELECT stock FROM product_skus WHERE id = 101 FOR UPDATE; -- FOR UPDATE 锁定行，防止并发修改
-- 如果库存充足，则更新库存
UPDATE product_skus SET stock = stock - 2 WHERE id = 101 AND stock >= 2;
-- 检查更新是否成功，即影响行数是否为1
-- 如果更新失败（库存不足），则回滚事务
-- 如果更新成功，则创建订单、订单项等
-- ...
COMMIT; -- 提交事务

这种“先查询后更新”并结合

FOR UPDATE

（悲观锁）或在

UPDATE

语句中加入

stock >= quantity

条件（乐观锁的变种）的方式，能有效保证库存的准确性。在实际高并发场景下，可能还需要引入消息队列异步处理库存扣减，或者使用Redis等缓存进行预扣减，再最终同步到数据库，但核心思想都是确保操作的原子性和隔离性。在订单项

order_items

表中，我们存储的是

sku_id

而不是

product_id

，这确保了订单明细能够精确追溯到具体的商品规格，从而避免了模糊不清的订单记录。

订单状态流转与支付逻辑如何设计，以应对复杂业务场景？

订单状态的流转是电商业务的核心流程之一，其设计需要兼顾业务的完整性、用户体验和系统的健壮性。支付逻辑更是重中之重，它直接关系到资金安全和交易的成功率。

在我的设计中，

orders

表的

order_status

和

payment_status

字段共同描绘了订单的生命周期。

订单状态流转 (order_status)：

待付款 (0)：用户提交订单后，尚未完成支付。此时订单已创建，但未生效。

待发货 (1)：用户完成支付后，订单进入待发货状态。商家可以开始处理订单。

待收货 (2)：商家发货后，订单进入待收货状态。此时会记录物流信息。

已完成 (3)：用户确认收货或系统自动确认收货后，订单完成。

已取消 (4)：在待付款阶段，用户或系统超时可取消订单。已支付的订单取消则会触发退款流程。

退款中 (5)：用户发起退款申请，或订单取消后需要退款，进入退款处理阶段。

已退款 (6)：退款成功，订单的资金已退回给用户。

这些状态的切换，通常是由用户的操作、支付回调、商家操作（发货）、定时任务（自动确认收货）等事件触发的。例如，从“待付款”到“待发货”的转变，关键在于支付成功的反馈。

支付逻辑设计：

支付逻辑通常涉及与第三方支付平台的交互，需要考虑幂等性、回调通知、异常处理等。

订单创建与支付请求： 用户提交订单，系统在
orders
表中创建一条记录，
order_status
为“待付款”，
payment_status
为“未支付”。同时，在
payments
表中创建一条支付记录，
status
为“待支付”，关联
order_id
。 系统引导用户跳转到支付平台进行支付，或调起支付SDK。

支付回调处理： 支付成功后，第三方支付平台会异步通知我们的系统（回调）。 系统接收到回调后，首先要进行签名验证，确保回调的真实性。 然后，根据回调中的交易号 (
transaction_id
) 和订单号 (
order_sn
)，查找对应的
payments
记录和
orders
记录。 幂等性处理：这是关键！支付平台可能重复回调，所以系统必须能够识别并处理重复通知。通常做法是，如果发现