📚 课程目录第1章课程导入

1. 课程导入

当单表数据量从百万级增长到十亿级，很多团队会突然发现：查询开始变慢、索引维护成本飙升、历史数据清理变成一场“删库式”冒险。此时，分区表往往是最先被想到、也最容易被误用的方案。它既不是简单的“把表拆开”，也不是一劳永逸的性能银弹，而是一种以数据生命周期为核心、以查询裁剪为手段、以可回滚为底线的物理设计策略。本课程将围绕“分区表设计兼顾性能优化与回滚”这一主线，带你从原理到落地，建立一套可验证、可回退、可演进的分区设计方法。

本课程的核心命题只有一句话：分区不是为了拆表，而是为了让“查询更快、维护更轻、回滚更稳”三件事同时成立。如果只追求查询性能而忽略回滚能力，分区就会变成新的技术债。

一、为什么分区表值得学：三个真实痛点

先看三个典型场景。第一，订单表按时间持续写入，三年前的数据几乎不再访问，但每次全表统计仍要扫描全部数据页；第二，日志表每天新增数千万行，DBA 需要定期删除 90 天前的数据，直接 DELETE 会产生巨大 undo 和主从延迟；第三，某次上线后发现分区键选择错误，导致大量跨分区查询，想回退却因为数据已按错误分区写入而无法快速恢复。这三个痛点分别对应查询裁剪、数据生命周期管理、可回滚设计，也正是本课程要解决的核心问题。

分区表的价值可以归纳为四点：

查询裁剪：优化器根据分区键自动排除无关分区，减少 I/O 与扫描行数。
维护解耦：按分区做归档、删除、重建索引，避免全表级锁与长事务。
写入分散：不同分区可落在不同表空间或磁盘，缓解热点。
回滚可控：分区边界清晰，便于按分区切换、备份与恢复，降低变更风险。

二、整体知识框架：从设计到回滚的六层结构

本课程不是零散技巧的堆砌，而是一条从“选型”到“回滚”的完整链路。下图展示了分区表设计的六层知识框架与实战路线图，后续章节将逐层展开。

这六层不是线性顺序，而是相互约束的闭环。例如分区键选择会直接影响查询裁剪效果，而查询裁剪效果又决定生命周期运维能否低成本执行；回滚方案则必须在设计阶段就预留，而不是上线后才补救。

三、方法流程：一个可落地的分区设计四步法

为了避免“拍脑袋分区”，建议采用以下四步法：

明确目标与约束：先回答“是为了查询快、还是为了清理快、还是为了回滚稳”。不同目标对应不同分区策略。
选择分区类型与键：时间范围分区适合日志、订单；列表分区适合地域、状态；哈希分区适合均匀打散；组合分区用于兼顾裁剪与均衡。
验证裁剪与倾斜：用真实 SQL 查看执行计划，确认分区裁剪生效；统计各分区行数，避免数据倾斜。
设计回滚路径：明确分区切换、备份恢复、灰度回退的具体命令与时间窗口。

一个实用原则：分区键必须出现在高频查询的 WHERE 条件中。如果查询从不带分区键，分区裁剪就不会发生，分区反而增加维护复杂度。

四、案例场景：订单表按时间分区

假设订单表 orders 每天新增 500 万行，查询主要集中在最近 30 天，历史数据保留 2 年。一个合理的按月范围分区定义如下：

CREATE TABLE orders (
  order_id      BIGINT NOT NULL,
  user_id       BIGINT NOT NULL,
  order_time    DATETIME NOT NULL,
  amount        DECIMAL(12,2),
  status        TINYINT,
  PRIMARY KEY (order_id, order_time)
)
PARTITION BY RANGE (TO_DAYS(order_time)) (
  PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01')),
  PARTITION p202402 VALUES LESS THAN (TO_DAYS('2024-03-01')),
  PARTITION p202403 VALUES LESS THAN (TO_DAYS('2024-04-01')),
  PARTITION pmax    VALUES LESS THAN MAXVALUE
);

这样设计后，查询最近 30 天数据时，优化器只需访问最近两个分区；清理历史数据时，可用 ALTER TABLE ... DROP PARTITION 秒级完成，而不是逐行删除。但要注意：pmax 分区是兜底，必须配合定期拆分，否则它会成为新的热点。

五、常见误区与复盘清单

误区	后果	正确做法
分区键与查询条件无关	无法裁剪，性能不升反降	让分区键出现在高频 WHERE 中
分区数量过多	元数据膨胀，DDL 变慢	按天/月合理粒度，控制分区总数
忽略 MAXVALUE 兜底	新数据写入失败	保留兜底分区并定期拆分
没有回滚方案	变更失败后无法快速恢复	设计阶段预留切换与备份路径
只测查询不测写入	上线后写入抖动	压测写入、归档、删除全链路

分区表不是“建完就完事”。它需要持续观测分区大小、裁剪命中率、写入延迟和归档任务。任何一次分区键调整，都应视为一次高风险变更，必须配套回滚脚本与演练。

六、学习目标与实战路线图

学完本课程，你应当能够：独立判断业务是否适合分区；选择合理的分区类型与键；写出可裁剪的高效 SQL；设计分区滚动与归档方案；并能在变更失败时快速回滚。后续内容将沿着“选型—设计—验证—运维—回滚”这条路线逐步展开，每一节都会给出可执行的命令、参数与检查清单。

最后记住：分区表设计的终点不是“分了多少区”，而是“查询更快、维护更轻、回滚更稳”三者同时达成。带着这个标准去学习每一节，你才能真正把分区表变成生产力，而不是新的技术负担。