订单表应按时间维度（推荐按月）分区，以隔离冷热数据、提升查询性能并简化归档清理；需用RANGE COLUMNS或TO_DAYS直接分区，避免函数导致剪枝失效，并定期维护分区。
订单表按时间维度分区是最常用也最有效的策略，核心是把历史数据和热数据物理隔离，提升查询性能、简化归档与清理。
为什么选时间维度做分区
订单数据天然具有强时间属性：新订单持续写入，老订单基本只读；按月或按天分区后，查询最近7天订单只需扫描1个分区，避免全表扫描。同时，删除3年前数据只需DROP PARTITION，比DELETE快几个数量级，还不会产生大量undo日志和碎片。
推荐分区粒度：按月分区（兼顾性能与管理）
太细（如按天）会导致分区数爆炸，增加元数据压力和维护成本；太粗（如按年）又削弱查询剪枝效果。按月是平衡点——一年最多12个分区，DDL操作轻量，且能较好支持“近3个月活跃查询+历史归档”这类典型场景。
- 起始分区建议从订单表最早数据月份开始，比如
202201 - 末尾预留2–3个未来分区（如已到2024年6月，建到202409），避免插入时自动新建分区带来的锁等待
- 使用
RANGE COLUMNS(order_time)（MySQL 5.7+）或DATE类型字段直接分区，避免用YEAR(order_time)等函数导致无法剪枝
实际建表语句示例（MySQL）
以下是一个按月 RANGE 分区的订单表结构片段：
CREATE TABLE `orders` (
`id` BIGINT NOT NULL,
`order_no` VARCHAR(32) NOT NULL,
`order_time` DATETIME NOT NULL,
`status` TINYINT DEFAULT 0,
PRIMARY KEY (`id`, `order_time`)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(`order_time`)) (
PARTITION p202201 VALUES LESS THAN (TO_DAYS('2022-02-01')),
PARTITION p202202 VALUES LESS THAN (TO_DAYS('2022-03-01')),
PARTITION p202203 VALUES LESS THAN (TO_DAYS('2022-04-01')),
...
PARTITION p202406 VALUES LESS THAN (TO_DAYS('2024-07-01')),
PARTITION p202407 VALUES LESS THAN (TO_DAYS('2024-08-01')),
PARTITION p202408 VALUES LESS THAN (TO_DAYS('2024-09-01')),
PARTITION p_future VALUES LESS THAN MAXVALUE
);
配套运维要点
分区不是一劳永逸，需配合定期维护：
- 每月初用
ALTER TABLE orders REORGANIZE PARTITION p_future INTO (...)拆分出下月分区 - 对超过保留期限的旧分区（如
p202201），先EXCHANGE PARTITION导出到归档表，再DROP，确保可追溯 - 在
WHERE条件中必须带上order_time范围（如order_time >= '2024-06-01'），优化器才能生效分区剪枝 - 避免在分区键上用函数，例如
WHERE DATE(order_time) = '2024-06-15'会强制扫描所有分区
基本上就这些。不复杂但容易忽略细节，关键是保持分区键干净、范围明确、维护节奏固定。
