MySQL仅存储订单数据，业务逻辑由应用层实现；订单表需含关键字段和复合索引；库存扣减须用带条件的UPDATE加事务；状态变更需限定来源状态；历史数据应归档以保障性能。
MySQL 本身不“实现”订单管理系统，它只负责可靠地存储和查询订单数据；真正的业务逻辑（比如下单、库存扣减、状态流转）必须由应用层（PHP/Java/Python 等）控制。直接在 MySQL 里用存储过程硬写完整订单流程，后期难调试、难测试、难协同，还容易引发死锁或事务失控。
订单表设计：别漏掉关键字段和索引
一个可用的 orders 表至少要包含：order_id（主键，建议用 BIGINT UNSIGNED 或 CHAR(32) 做雪花ID）、user_id、status（如 'pending', 'paid', 'shipped', 'cancelled'）、total_amount、created_at、updated_at。不要用 ENUM 存状态——改状态要 ALTER TABLE，线上不敢动。
必须加的索引：
-
INDEX idx_user_status (user_id, status)：用户查自己所有订单+按状态筛选 -
INDEX idx_status_created (status, created_at)：运营查某类状态的最新订单 - 如果经常按时间范围导出，
created_at单独建索引也有必要
下单时的库存扣减：必须用事务 + 行锁，不能靠应用层判断
典型错误是先 SELECT stock FROM products WHERE id = ?，再判断够不够，最后 UPDATE。这中间有竞态：两个请求同时读到库存=1，都判定可下单，结果超卖。
正确做法（在应用层开启事务后执行）：
UPDATE products SET stock = stock - 1 WHERE id = ? AND stock >= 1;
然后检查 ROW_COUNT() 是否为 1。返回 0？说明库存不足或已被抢走，立刻回滚事务。这个 WHERE 条件里的 stock >= 1 是关键，它让 UPDATE 自带校验，且会锁定该行。
订单状态变更：禁止直接 UPDATE status = 'xxx'，要用状态机约束
允许从 pending → paid，但不允许 paid → pending，更不允许跳过中间状态（如 pending → shipped）。硬编码判断太脆弱，建议在 UPDATE 语句里显式限定来源状态：
UPDATE orders SET status = 'paid', updated_at = NOW() WHERE order_id = ? AND status = 'pending';
如果影响行为 0，说明当前状态不是 pending，应用层就该报错而不是静默失败。比在代码里 if-else 判断更可靠，也避免因缓存或并发导致状态错乱。
历史订单归档：别让主表越长越大
订单表数据只增不删，一年后单表破千万行很常见。这时 SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20 可能变慢——即使有索引，深度分页（如第 1000 页）也会拖垮性能。
可行方案：
- 按月分表（如
orders_202401,orders_202402），用应用路由，老表转为只读并迁到低配实例 - 或用 MySQL 8.0+ 的
PARTITION BY RANGE (TO_DAYS(created_at))，但注意分区键必须是主键一部分，且维护成本不低 - 更轻量的做法：保留近 6 个月数据在主表，旧数据移入
orders_archive，查历史时主动指定表名
归档动作务必在低峰期用小批量（每次 1000 行）+ 事务执行，并监控 innodb_row_lock_waits，避免阻塞线上下单。
