商品基础字段怎么定：别一上来就加几十个字段
商品表最怕“想太多”，比如提前加
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，否则订单、评价、日志里的外键全断，历史数据就废了。
