mysql如何设计商品表结构_mysql电商项目入门_网络技术

商品基础字段应精简：仅保留id、name、category_id、price（DECIMAL）、cost_price、status、created_at、updated_at；规格拆至product_spec和product_sku表；图片和详情分离存储；状态管理用publish_status+published_at；删除改用is_deleted软删。

商品基础字段怎么定：别一上来就加几十个字段

商品表最怕“想太多”，比如提前加 sku_weight、warehouse_code 这类后期才用的字段。初期只保留强依赖字段：id、name、category_id、price、cost_price、status（0下架/1上架）、created_at、updated_at。其中 price 用 DECIMAL(10,2)，不是 FLOAT——浮点数会导致价格计算偏差，比如 0.1 + 0.2 ≠ 0.3。

常见错误是把所有属性塞进一张表：颜色、尺寸、

材质全用 JSON 存。这会让搜索、分页、索引失效。正确做法是拆出 product_spec 表存规格项，product_sku 表存具体 SKU，主表只管“商品本体”。

SKU 和规格怎么关联：避免用字符串拼接做组合键

很多新手用 CONCAT(color, '-', size) 当 SKU 编码，再存在 product_sku 表里当主键。问题来了：查询某颜色所有尺码时得用 LIKE 'red-%'，没法走索引；改规格名还得批量更新字符串。

更稳的做法是：

product_spec 表存独立规格项：id、spec_key（如 'color'）、spec_value（如 'red'）
product_spec_value 表记录商品与规格值的多对多关系：product_id、spec_value_id
product_sku 表用自增 id 主键，通过 JSON 或关联表存规格组合（推荐后者，便于约束和查询）

MySQL 5.7+ 支持 JSON_CONTAINS，但复杂查询性能差，别依赖它做核心筛选逻辑。

图片和详情怎么存：别把大字段塞进主表

product 主表里加 detail_html 或 images_json 字段，看着省事，实际会拖慢所有 SELECT * 查询，还影响备份速度和主从同步延迟。

建议分离：

图片地址统一存 product_image 表，字段： product_id、url、sort_order、is_primary
富文本详情存 product_detail 表，用 MEDIUMTEXT，按需 JOIN
如果要用全文检索，name 和 brief 单独建 FULLTEXT 索引，别对 detail_html 建

另外，图片 URL 别存相对路径或本地文件路径，必须是可直接访问的绝对 URL，否则前端渲染就报 404。

状态和上下架逻辑：别只靠 status 字段硬控制

单纯用 status 字段区分“上架/下架”，上线后很快会遇到新需求：定时上架、草稿态、审核中、库存为 0 时自动下架……这时候光靠一个字段撑不住。

更可持续的设计是：

加 publish_status（draft/pending/published/failed）管发布流程
加 published_at 时间戳，配合定时任务检查是否到时间自动切状态
库存相关下架逻辑放到应用层或触发器里判断，不要在 SELECT 商品列表时动态算 stock > 0——容易误判，尤其高并发减库存场景

还有一个隐形坑：商品删除。永远别用 DELETE FROM product，而是加 is_deleted TINYINT DEFAULT 0，否则订单、评价、日志里的外键全断，历史数据就废了。

# mysql # html # js # 前端 # json # go # 编码 # ai # cos # red # Float # select # 字符串 # delete # 并发 # default # 下架 # 上架 # 塞进 # 主键 # 看着 # 来了 # 太多 # 这类 # 要用 # 还有一个

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】