商品基础字段应精简：仅保留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，否则订单、评价、日志里的外键全断，历史数据就废了。
