订单主表必须拆分为order和order_summary表，前者存order_id、user_id等核心字段，后者存金额、优惠等聚合字段；order_item需冗余商品快照信息；状态用tinyint枚举并配order_status_log日志表；分库前先垂直拆分交易与风控数据。
订单主表必须拆分 order 和 order_summary
电商订单量大、查询场景多，把所有字段塞进一张 order 表会导致频繁的锁竞争和慢查询。真实生产中，order 表只存核心不可变字段，比如 order_id、user_id、status、created_at；而金额、优惠、运费等易聚合或需频繁统计的字段，应剥离到 order_summary 表，用 order_id 关联。
这样做有两个实际好处：一是 order 表能加更细粒度的索引（比如按 user_id + status 查用户订单），二是避免大字段（如 JSON 格式的优惠明细）拖慢高频查询。
常见错误是把所有字段堆在一张表里，结果一查“用户最近 10 笔订单”，就触发 Using filesort 和全表扫描。
order_item 表必须冗余商品快照信息
下单那一刻，商品价格、名称、SKU 编码、库存状态都必须固化进 order_item 表，不能只存 product_id 后期靠 JOIN 查询。否则商品下架、改名、调价后，历史订单会显示错乱，财务对账直接出问题。
冗余字段至少包括：product_name、sku_code、price_at_order、quantity、snapshot_json（存当时规格参数，如颜色/尺码）。
注意：不要用 TEXT 存快照 JSON，推荐 JSON 类型（MySQL 5.7+），方便后续用 JSON_EXTRACT() 查询，也支持生成虚拟列建索引。
状态流转必须用整型枚举 + 状态机日志表
别用字符串存 status 字段（如 'paid'、'shipped'），统一用 tinyint，比如：1=created, 2=paid, 3=confirmed, 4=shipped, 5=completed, 6=canceled。好处是排序快、索引小、不易拼错。
HTShop网上购物系统由恒天网络科技有限公司根据国际先进技术和国内商务特点自主版权开发的一款具有强大功能的B2C电子商务网上购物平台。HTShop以国际上通用流行的B/S(浏览器/服务器)模式进行设计，采用微软公司的ASP.NET（C#）技术构建而成。 2007-11-10 HTShop CS 通用标准版 v1.1.11.10 更新内容自由更换模版功能开放 修改了购买多款商品，会员中心订单只显示
但光靠一个字段不够——你得知道谁在什么时候把订单从“已支付”改成“已发货”。所以必须配一张 order_status_log 表，字段包括：order_id、from_status、to_status、operator_id、remark、created_at。
关键点：状态变更必须走事务，先 INSERT 日志，再 UPDATE 主表，防止日志丢失导致状态不可追溯。
分库分表前先做垂直拆分，尤其隔离交易与风控数据
刚起步时别急着 ShardingSphere 或 MyCat 分库，先做垂直切分：把订单核心链路（order、order_item、order_payment）放一个库，把风控规则、用户行为埋点、物流轨迹这些低一致性要求的数据，挪到其他库。
理由很实在：订单库要扛住秒杀写入峰值，而风控数据可以容忍延迟几秒同步；混在一起反而让主库被慢查询拖垮。
容易忽略的是：跨库关联查询（比如“查某用户所有订单 + 对应风控评分”）必须收口到应用层，用两次查询 + 内存 join，别指望 MySQL 联合多个物理库。
真正需要水平分表，通常出现在单表行数超 2000 万、日增订单超 50 万之后，那时再按 user_id 或 order_id 哈希分片也不迟。
