订单主表必须用order_id主键，禁用auto_increment；推荐雪花id（bigint unsigned）或uuid（char(36)）；status用tinyint枚举；金额全用decimal(12,2)；拆分order_item/order_address表；时间统一存utc。
订单主表必须用 order_id 作为主键，别用 auto_increment 整数
用户下单并发高、分库分表后 ID 易冲突，auto_increment 在多实例下根本不可靠。直接用 UUID 或雪花算法生成的 BIGINT 更稳妥——前者兼容性好但存储和索引效率略低，后者性能优但需额外服务支撑。
实操建议：
-
order_id类型选BIGINT UNSIGNED（若用雪花 ID）或CHAR(36)（UUID v4），**别用VARCHAR(36)**——固定长度让 InnoDB 更省空间 - 加
UNIQUE约束，防重复插入；同时建INDEX在常用查询字段上，比如user_id、status、created_at - 避免把
order_no（业务单号，如 “ORD202405200001”）设为主键——它不满足唯一性保障，且字符串比数字慢
状态字段用 TINYINT 枚举值，别用字符串或 JSON
订单状态（待支付、已发货、已完成、已取消）频繁被 WHERE 查询和 GROUP BY 统计，字符串匹配慢、索引失效风险高，JSON 更是彻底放弃索引能力。
实操建议：
- 定义
status TINYINT NOT NULL DEFAULT 1，配合注释说明：1=待支付，2=已支付，3=已发货，4=已完成，5=已取消，99=异常 - 应用层用常量映射，别硬编码数字；数据库不建 CHECK 约束（MySQL 8.0.16+ 才支持，老版本无效）
- 需要状态流转日志？另建
order_status_log表，主表只存当前态——避免大字段拖慢主表查询
金额字段统一用 DECIMAL(12,2)，别用 FLOAT 或 DOUBLE
浮点类型在存储和计算中存在精度丢失，比如 0.1 + 0.2 != 0.3，金融类场景绝对不能碰。哪怕只是“运费”“优惠券抵扣”，也必须精确到分。
实操建议：
- 所有金额字段（
total_amount、pay_amount、freight、discount）都用DECIMAL(12,2)——12 位总长含 2 位小数，够覆盖百万级订单金额 - 别为了“省两位”用
DECIMAL(10,2)：万一将来要支持跨境多币种（如 USD/JPY），汇率乘积可能突破 10 位 - 应用写入前务必做四舍五入（PHP 的
round($val, 2, PHP_ROUND_HALF_UP)，Java 的BigDecimal.setScale(2, RoundingMode.HALF_UP)），否则 MySQL 会自动截断，导致账不平
关联数据别全堆在订单主表，拆出 order_item 和 order_address
一个订单可能含 1–50 个商品，地址信息也可能随时间变化（用户改收货地址），全塞进主表会导致行太宽、更新锁竞争激烈、历史快照无法保留。
实操建议：
-
order_item表必须有order_id+sku_id联合唯一索引（防重复加购），字段至少含：quantity、price（快照当时售价）、name（快照商品名） -
order_address表存下单时的完整地址快照，字段包括：consignee、phone、province/city/district、detail——别只存用户 ID 去关联用户表 - 主表只留必要字段：状态、金额、用户 ID、创建/更新时间；其他一律外键关联——既控制宽度，又方便按需 JOIN
最易被忽略的是时间字段的精度和时区。别用 DATETIME 存 UTC 时间却用本地时区读取，也别依赖 MySQL 默认时区——应用写入时就该用 UTC 格式（如 NOW() AT TIME ZONE '+00:00'），所有客户端统一按 UTC 解析再转本地显示。
