Shopware 6订单相关表数据库分区实践经验与案例求助

案例1：按订单创建时间范围分区（MySQL） #

场景：电商订单表，数据随时间自然增长，90%的业务查询集中在近6个月的订单，历史订单仅用于季度对账。
分区策略：

• 采用RANGE分区，以create_time为分区键，每个分区对应1个月的数据，额外设置一个默认分区承接未来数据
• 核心DDL示例：

ALTER TABLE orders 
PARTITION BY RANGE (TO_DAYS(create_time)) (
    PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
    PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
    ...
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

效果：

• 日常查询仅扫描目标时间范围的分区，查询速度提升4-6倍
• 历史分区可单独归档至低成本存储，降低主库存储压力

案例2：按订单状态列表分区（PostgreSQL） #

场景：O2O平台订单表，订单状态分为「待支付」「已完成」「已取消」等，业务频繁单独查询某一状态的订单（比如统计已完成订单的月度营收）。
分区策略：

• 采用LIST分区，以order_status为分区键，每个状态对应独立分区，设置默认分区处理异常状态
• 核心DDL示例：

CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    order_status INT,
    create_time TIMESTAMP,
    amount NUMERIC
) PARTITION BY LIST (order_status);

CREATE TABLE orders_pending PARTITION OF orders FOR VALUES IN (1);
CREATE TABLE orders_completed PARTITION OF orders FOR VALUES IN (2);
CREATE TABLE orders_canceled PARTITION OF orders FOR VALUES IN (3);
CREATE TABLE orders_default PARTITION OF orders DEFAULT;

效果：

• 查询特定状态订单时仅扫描对应分区，比全表扫描速度提升3倍以上
• 可针对活跃状态（如待支付）的分区单独配置高性能存储介质

案例3：按用户ID哈希分区（Oracle） #

场景：SaaS平台订单表，用户分布均匀，业务常按用户维度查询历史订单（比如用户个人中心的订单列表）。
分区策略：

• 采用HASH分区，以user_id为分区键，划分成8个分区（数量可根据服务器CPU核心数调整）
• 核心DDL示例：

CREATE TABLE orders (
    order_id NUMBER,
    user_id NUMBER,
    create_time DATE,
    amount NUMBER
) PARTITION BY HASH(user_id) PARTITIONS 8;

效果：

• 数据均匀分布到各分区，避免单分区数据过载
• 用户维度查询时仅扫描对应哈希分区，并发查询性能显著提升

关键注意事项 #

• 分区键必须与业务查询的过滤条件高度匹配，否则会触发全分区扫描（比如用时间分区但查询不带时间条件）
• 避免过度分区，分区数量过多会增加元数据管理的开销
• 分区后同步调整索引策略，优先为每个分区创建本地索引，而非全局索引

内容的提问来源于stack exchange，提问作者Marcin Kaczor