1. 课程导入与场景锚定
在证券、期货、期权等交易系统中，逐笔行情（Tick-by-Tick Market Data）是最细粒度、最贴近真实撮合过程的一类数据。它记录的不只是某一时刻的最新价，而是每一笔成交、每一次委托簿变化、每一档行情快照的完整轨迹。对于量化研究、交易回放、合规审计、异常交易监控等场景，逐笔行情往往是不可替代的原始素材。本课程以真实逐笔行情数据为对象，以分区表设计为主线，目标不是讲清某一种数据库语法，而是建立一套“面对海量时序行情，如何组织存储、如何切分、如何查询、如何运维”的完整工程方法。
逐笔行情数据的业务特征
要设计好分区表，先要理解数据本身长什么样。逐笔行情通常具备以下几个鲜明特征：
- 强时序性：每条记录都带有交易所时间戳（精确到毫秒甚至纳秒），数据天然按时间先后排列，写入基本是追加式的，极少更新历史记录。
- 高吞吐、大体积：以沪深两市为例，单日全市场逐笔成交与委托数据可达数十亿条量级，压缩前原始体量常在数百 GB 到 TB 级；若叠加期权、期货多市场，规模进一步放大。
- 字段结构相对固定：证券代码、市场类型、业务类型（成交/委托/快照）、时间戳、价格、数量、买卖方向、序号等字段稳定，适合列式或宽表存储。
- 查询模式高度集中：绝大多数查询都带“时间范围 + 证券代码”两个条件，例如“回放某只股票某日上午的逐笔成交”“统计某合约某日的委托簿变化”。
- 冷热分层明显：最近几日的数据被频繁访问，历史数据主要用于回溯与审计，访问频率骤降。
这些特征决定了：逐笔行情不是普通的业务表，而是一张“按时间无限增长、按代码频繁过滤、按日期冷热分化”的时序宽表。分区表设计必须围绕这些特征展开，而不是套用通用建模模板。
规模挑战：为什么普通单表会失效
如果把一年的逐笔行情塞进一张普通表，会迅速遇到几类问题。第一是写入与索引维护成本：B+ 树索引在数十亿行规模下，每次插入都可能触发页分裂与随机 I/O，写入吞吐急剧下降。第二是查询剪枝失效：即使查询只关心某一天的数据，优化器仍可能扫描大量无关数据页，延迟不可控。第三是运维困难：单表过大导致备份、恢复、DDL 变更、数据清理都变成高风险操作，删除一年前的数据往往要执行代价极高的批量 DELETE。第四是冷热数据无法差异化处理：热数据需要高性能存储，冷数据希望低成本归档，单表结构下难以按时间粒度做存储策略。
分区表正是针对这些痛点的手段：通过把一张逻辑大表按某个维度切分为多个物理分区，实现写入分散、查询剪枝、按分区维护与按分区生命周期管理。关键在于——切分维度选什么、粒度多粗、分区内如何组织，直接决定了这套设计是否真正好用。
分区表设计的核心目标
结合逐笔行情的特征，本课程把分区表设计的核心目标归纳为四条，后续章节的每一个决策都将回到这四条上检验：
- 写入可扩展：数据按时间持续追加时，写入压力能分散到不同分区，避免单点热点，保证高峰时段（如开盘集合竞价、尾盘）的写入吞吐。
- 查询可剪枝：带时间范围和证券代码的典型查询，能够通过分区裁剪只扫描必要分区，把扫描量从“全表”降到“单日甚至单小时”。
- 生命周期可管理：历史数据可以按分区整体归档、迁移或删除，避免大事务，降低运维风险。
- 冷热可分层：不同时间分区可以放置在不同存储介质或表空间上，让热数据享受高性能、冷数据享受低成本。
下图把逐笔行情的业务特征、规模挑战与分区设计目标串联起来，帮助建立本节的整体认知框架：
一个具体的规模估算示例
为了让“规模挑战”有可感知的量级，这里给出一个合理假设的估算示例（非实测数据，仅用于教学说明）。假设某市场单日逐笔成交约 8 亿条、逐笔委托约 12 亿条，单条记录压缩后平均约 40 字节，则单日原始数据量约为 (8+12) 亿 × 40 B ≈ 80 GB。按一年 250 个交易日计算，年增量约 20 TB。若采用单表存储，一年后这张表将承载约 5000 亿行。此时一次“查询某只股票某日全部逐笔”的请求，如果无法有效剪枝，扫描代价将难以接受；而一次“删除三年前数据”的批量操作，可能锁表数小时。反过来，如果按“交易日”做范围分区，每天一个分区，那么上述查询只需命中 1 个分区，删除历史数据只需 DROP 对应分区，代价从“小时级”降到“秒级”。这就是分区设计带来的直接收益，也是本课程后续要反复验证的判断依据。
本课程的组织方式
围绕上述目标，课程将沿着一条工程主线推进：先明确逐笔行情的字段模型与查询画像，再讨论分区键与分区粒度的选择（时间范围分区、列表分区、哈希子分区的组合），接着进入分区表的物理实现与索引策略，然后覆盖写入链路、查询剪枝验证、冷热分层与生命周期管理，最后通过排障与复盘把设计落到可运维的层面。每一节都会尽量给出可执行的参数、示例与判断标准，而不是停留在概念层面。本节作为导入，只需要记住一件事：逐笔行情的分区表设计，本质是用“时间切分”换取写入扩展性、查询剪枝能力和运维可控性，后续所有设计决策都应回到这个出发点来检验。