订单表设计需聚焦主流程，用tinyint存status枚举、decimal存金额、拆分order_items和user_addresses表；查用户最近5笔未完成订单须建(user_id, status, created_at)联合索引；状态更新要条件原子写法并校验ROW_COUNT()；退款必须FOR UPDATE加行锁+事务内强一致性校验。
订单表怎么设计才不翻车
订单管理的核心是数据结构得扛得住业务变化。别一上来就加一堆字段，先想清楚主流程：下单 → 支付 → 发货 → 完成/退款。对应到表里，orders 至少要有：order_id（主键，推荐用 BIGINT UNSIGNED 或 CHAR(32) 做雪花ID）、user_id、status（用 tinyint 存枚举值，比如 1=待支付、2=已支付、3=已发货、4=已完成、5=已取消）、total_amount（decimal(10,2)，别用 float）、created_at 和 updated_at。
容易踩的坑：
-
status别用字符串存（如 'paid'），查起来慢还容易拼错； - 别把商品快照全塞进
orders表，应该拆出order_items表，关联order_id+product_id+quantity+price_at_order（下单时的价格，不是实时价）； - 用户地址别只存个
address_text字段，要单独建user_addresses表，订单里只存address_id，方便复用和修改历史单地址。
怎么查“某个用户最近5笔未完成订单”
这是后台和App最常调的接口之一，SQL 写法直接影响响应速度。基础写法是：
SELECT * FROM orders WHERE user_id = 123 AND status IN (1, 2, 3) ORDER BY created_at DESC LIMIT 5;
但要注意三点：
- 必须给
(user_id, status, created_at)建联合索引，顺序不能错——user_id在前是范围查询前提； - 如果
status只有少数几个值，且查询条件固定（比如永远查“未完成”），可以把status IN (1,2,3)换成status < 4，某些版本 MySQL 优化器对数字比较更友好； - 别在 SELECT * 里带大字段（比如
json_extra），真需要再用子查询或 JOIN 补。
更新订单状态时为什么总丢数据
并发场景下，比如支付回调和用户手动取消同时到达，直接 UPDATE orders SET status = 2 WHERE order_id = 1001 会覆盖彼此。正确做法是带条件原子更新：
UPDATE orders SET status = 2, updated_at = NOW() WHERE order_id = 1001 AND status = 1; -- 确保只从“待支付”升为“已支付”
执行后检查 ROW_COUNT() 返回值：
- 返回 1：更新成功；
- 返回 0：说明原状态不是 1（可能已被其他流程改过），这时该报错还是重试，由业务逻辑定；
- 千万别忽略这个返回值，否则“支付成功”消息发出去了，数据库其实没变。
退款操作怎么保证金额对得上
订单总金额、已退金额、剩余可退金额必须强一致。不要靠应用层算，要在数据库里锁住再校验：
START TRANSACTION;
SELECT total_amount, refunded_amount
FROM orders
WHERE order_id = 1001
FOR UPDATE; -- 加行锁，防并发修改
-- 应用层判断：if (total_amount - refunded_amount >= refund_now) { ... }
UPDATE orders
SET refunded_amount = refunded_amount + 50.00
WHERE order_id = 1001;
INSERT INTO refunds (order_id, amount, reason)
VALUES (1001, 50.00, 'user_request');
COMMIT;关键点：
- 必须用
FOR UPDATE，不能只靠 WHERE 条件； - 所有涉及金额的操作（包括优惠券核销、积分抵扣）都得走同一事务，否则对不上；
-
refunded_amount字段类型也必须是DECIMAL(10,2)，和total_amount一致，避免浮点累加误差。
实际项目里，订单状态流转和资金动作往往跨多个服务，MySQL 单库能兜住初级业务，但一旦出现“支付成功但订单没改状态”这类问题，第一反应不该是加日志，而是检查事务边界有没有被意外中断——比如用了 ORM 的自动 commit 模式，或者中间 throw 了没 catch 住 rollback。
