PHP电商系统怎样设计商品与订单数据表-php教程-PHP中文网

商品表核心字段包括：goods_id（bigint unsigned主键）、sku（唯一非空字段，用于订单和仓配对账）、price与market_price分离存储、status用tinyint(1)存状态码；不存库存、不冗余展示字段，确保支撑订单、库存、搜索、促销等业务逻辑。

php电商系统怎样设计商品与订单数据表

商品表不是用来展示的，是给订单、库存、搜索、促销逻辑提供准确数据的。核心矛盾在于：字段太少，后续加活动、规格、多仓库就崩；字段太多，日常查 SELECT * 拖慢首页。

goods_id 必须是主键且用 BIGINT UNSIGNED，别用 INT——中大型电商半年就超 2147 万条
sku 字段必须存在且唯一（不是主键），它是订单关联和仓配系统的事实主键，别指望靠 goods_id 去对账
price 和 market_price 分开存，促销时只改 price，前端展示逻辑才不会错乱
别在商品表里存库存数量——stock 属于 SKU 级别，必须拆到 goods_sku 表，否则多规格商品（如颜色+尺寸）根本没法算
status 用 tinyint(1) 存状态码（如 1=上架, 2=下架, 3=审核中），别用字符串，避免 WHERE status = 'on_sale' 这种低效查询

合表看着省事，上线三个月后就会遇到两个硬伤：一是订单导出慢（JOIN 商品表 + 分类表 + 用户地址表），二是无法做订单快照——商品改价或下架后，历史订单金额就对不上。

订单主表 order 只存全局信息：order_no（唯一索引）、user_id、total_amount、status、created_at
订单明细表 order_item 必须包含当时快照：goods_name、sku_code、price、quantity、spec_info（JSON 字段，存“黑色/L”这类文本，不关联规格表）
order_item.goods_id 和 order_item.sku_id 都要保留，前者用于统计销量，后者用于仓配拣货
别给 order_item 加外键约束——高并发下单时，InnoDB 的外键检查会成为性能瓶颈

只用一个 status 字段存 1/2/3/4，会导致无法回溯“谁在什么时候把订单从待付款改成已发货”，也撑不住售后流程（比如“已发货→申请退货→退货中→已退款”这种分支）。

PHP 8.5.5

PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。

下载

必须建独立的状态流转表 order_status_log，字段至少含：order_id、from_status、to_status、operator_type（'user'/'admin'/'system'）、created_at
每次状态变更都 INSERT 一条日志，而不是 UPDATE 主表 status——这样查纠纷单时才能明确责任节点
order.status 字段只存当前值，用于列表页快速筛选；所有业务判断（如“能否取消”）必须查最新一条 order_status_log 记录，而不是直接读 order.status

开发阶段调通就行，上线后第一条慢查询往往就卡在这几个地方。

所有表必须用 InnoDB，别用 MyISAM——事务、行锁、外键支持缺一不可，尤其订单支付回调必须事务保证
order_no 字段建唯一索引，但别设为 PRIMARY KEY（主键还是用自增 id），否则分库分表时迁移成本爆炸
商品搜索常用字段（如 name、category_id）要联合建索引，例如 INDEX idx_cat_status (category_id, status)，别指望单列索引扛住并发筛选
全部表用 utf8mb4 字符集，否则用户收货地址里存个 ? 或 emoji 就报错；collation 统一用 utf8mb4_unicode_ci，避免大小写比较出问题