电商系统中订单表的设计需要兼顾数据完整性、查询效率和业务扩展性。MySQL作为常用数据库，合理设计订单表结构是系统稳定运行的基础。核心思路是将订单主信息与明细分离，保证高内聚低耦合。

1. 订单主表（order_info）

存储订单的基本信息，每条记录对应一个订单。

• order_id：订单唯一编号，建议使用分布式ID（如雪花算法）或带业务前缀的字符串，避免自增ID暴露业务量
• user_id：用户ID，建立索引便于按用户查询订单
• order_status：订单状态（如待支付、已支付、已发货、已完成、已取消），用整型+字典表管理更灵活
• total_amount：订单总金额，精确到分，用DECIMAL(10,2)
• pay_amount：实际支付金额，支持优惠后价格
• pay_type：支付方式（支付宝、微信、银联等）
• consignee_info：收货人信息（姓名、电话、地址），可单独拆出收货表，但多数场景可保留在此提高查询效率
• create_time：订单创建时间，建立索引支持按时间筛选
• update_time：最后更新时间，自动更新
• delete_flag：逻辑删除标记，软删除更安全

2. 订单商品明细表（order_item）

存储订单中每个商品的详细信息，支持一单多品。

• item_id：明细ID，主键
• order_id：外键关联主表，建立索引
• product_id：商品ID
• product_name：商品名称，冗余存储避免后期商品改名导致历史数据失真
• price：下单时单价，防止价格变动影响历史订单
• quantity：购买数量
• subtotal：小计金额，方便快速统计
• spec_info：规格信息（如颜色、尺寸），JSON格式存储较灵活

3. 订单操作日志表（order_log）

记录订单状态变更过程，用于审计和问题排查。

• log_id：日志ID
• order_id：关联订单
• status_from：原状态
• status_to：目标状态
• operator：操作人（用户或系统）
• operate_time：操作时间
• remark：备注，如取消原因

关键设计考虑点

实际开发中还需注意：

• 订单号不宜用自增ID，可用“日期+用户ID后四位+随机数”组合防爬取
• 涉及金额字段统一用DECIMAL，避免浮点误差
• 高频查询字段建立复合索引，如(user_id, create_time)
• 大字段（如地址、备注）避免频繁更新，必要时拆表
• 订单表数据量大，需提前规划分库分表策略，如按user_id哈希或按时间范围切分

基本上就这些。结构清晰、字段合理、索引到位，就能支撑大多数电商场景。