订单表怎么设计才不翻车
订单管理的核心是数据结构得扛得住业务变化。别一上来就加一堆字段，先想清楚主流程：下单 → 支付 → 发货 → 完成/退款。对应到表里，
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 ，某些版本 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。
